similar to: Re: NULL pointer dereference in context_acquire(), wined3d/conte

In context_acquire(), line 2439 (as of commit 90e3bc5, fetched just now), I'm seeing the line struct wined3d_swapchain *swapchain = device->swapchains[0]; crash because device->swapchains is NULL. This happens in the games Club Paradise and Spa Mania when switching between fullscreen and windowed mode. The platform is Ubuntu Desktop 32-bit 11.04 with the Recommended version of the

> In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is > assigned to mode, which will lead to a possible NULL pointer dereference > on failure of drm_mode_duplicate(). Add a check to avoid npd. Can a wording approach (like the following) be a better change description? A null pointer is stored in the local variable ?mode? after a call of the function

> In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. A) Can a wording approach (like the following) be a better change description? A null pointer is stored in the local variable ?mode? after a call of the function

> In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is > assigned to mode, which will lead to a possible NULL pointer dereference > on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). > Add a check to avoid null pointer dereference. Can a wording approach (like the following) be a better change description? A null pointer is stored in the local

We've just started seeing this. Anyone else? reason: BUG: unable to handle kernel NULL pointer dereference at 00000000000000b8 component: kernel count: 1 analyzer: vmcore architecture: x86_64 event_log: kernel: 3.10.0-327.18.2.el7.x86_64 last_occurrence: 1484067452 os_release: CentOS Linux release 7.3.1611 (Core) runlevel: N 3 time:

Hi all, Writing my own LLVM client I've noticed a potential null pointer dereference in EngineBuilder::selectTarget. The class has an optional pointer to the ErrorStr, which can be initialzied through setErrorStr() method. Although, it's strictly optional, selectTarget doesn't verify its value before assignment. Please find patch for branch release_31, revision 155051 attached. -

Hi Yury, No need for the "{" "}" since it's a single statement in the compound statement. Other than that minor style detail, this looks fine assuming it applies cleanly to trunk. Do you have commit access? Regards, -Jim On May 9, 2012, at 3:40 PM, Yury Mikhaylov wrote: > Hi all, > > Writing my own LLVM client I've noticed a potential null pointer

Thank you for your response Jim. As of revision 153342 it applies properly to trunk. No, unfortunately I don't have access, would you please commit it for me? Thanks, Yury On Wed, May 9, 2012 at 4:37 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Yury, > > No need for the "{" "}" since it's a single statement in the compound > statement.

https://bugs.freedesktop.org/show_bug.cgi?id=105173 Pierre Moreau <pierre.morrow at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[MCP79][Regression] |[MCP79][Regression] |Unhandled NULL pointer |Unhandled NULL pointer

If output is NULL it is not permissable to dereference it. So we should leave the respective function in this case. The inconsistency was indicated by cppcheck. No actual NULL pointer dereference was observed. Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

If output is NULL it is not permissable to dereference it. So we should leave the respective function in this case. The inconsistency was indicated by cppcheck. No actual NULL pointer dereference was observed. Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Signed-off-by: Ma Ke <make_ruc2021 at 163.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c

In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. Signed-off-by: Ma Ke <make_ruc2021 at 163.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++++ 1 file changed, 4 insertions(+)

Reviewed-by: Lyude Paul <lyude at redhat.com> I will push this and the other patch that you sent upstream in just a moment, thanks! On Tue, 2024-06-25 at 16:10 +0800, Ma Ke wrote: > In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() > is > assigned to mode, which will lead to a possible NULL pointer > dereference > on failure of drm_mode_duplicate(). The

> In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. 1. Can a wording approach (like the following) be a better change description? A null pointer is stored in the local variable ?mode? after a call of the function

On Wed, 26 Jun 2024, Ma Ke <make24 at iscas.ac.cn> wrote: > In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. > > Signed-off-by: Ma Ke <make24 at iscas.ac.cn> > --- >

Ma Ke - I assume you already know but you can just ignore this message from Markus as it is just spam. Sorry about the trouble! Markus, you've already been asked by Greg so I will ask a bit more sternly in case there is actually a person on the other end: you've already been asked to stop by Greg and are being ignored by multiple kernel maintainers. If I keep seeing messages like this

I was curious if this was a real null pointer dereference issue in R-devel/src/library/grDevices/src/devPS.c on line 1009? 1000: static type1fontinfo makeType1Font() 1001: { 1002: type1fontinfo font = (Type1FontInfo *) malloc(sizeof(Type1FontInfo)); 1003: /* 1004: * Initialise font->metrics.KernPairs to NULL 1005: * so that we know NOT to free it if we fail to 1006: *

Hi! I tried to use cdrdao on 2.5.5x kernels but kernel gives me following messages. Further debugging reveals that sb is NULL in __ext3_std_error() function. I tried this on ext2 and it seems it isn't ext3 specific, on ext2 it also doesn't work. cdrdao is after this in D state and is unkillable, but the CD-ROM drive from which I tried to grab is perfectly usable. This happens to me

Author: jojemann Repository: /hg/zfs-crypto/gate Revision: aa51fc8a43798383cb3ead8c97bcad88acd305c5 Log message: 6283314 frequent panics in ipf:fr_movequeue: NULL pointer dereference 6294902 ipfilter doesn''t recognize TCP window scale option correctly. Files: update: usr/src/common/ipf/ip_state.c