Bug#469642: Signal 11 at libGLcore.so(_mesa_update_draw_buffer_bounds+0x59)

2008-03-11 Thread Brice Goglin
tags 469642 +moreinfo
thank you



Sergio Gelato wrote:
 * Brice Goglin [2008-03-10 19:51:06 +0100]:
   
 The crash is in the Mesa built-in the server, and this mesa 6.5.1 is very 
 old.
 So please try to reproduce with a more recent Xserver built against a recent 
 Mesa.
 xserver-xorg-core from testing would be much better already.
 

 Sorry, but the affected computer is in production and not available for
 further testing. I (reluctantly) switched to the proprietary nvidia
 driver as a workaround, and that worked out to the user's satisfaction.
   

Does this mean that you will never be able to do some testing again? Or
do we just have to wait a bit (long)?

I am marking the bug the bug as moreinfo for now.

 As with all problems that have only been observed on one machine, one
 wonders whether it might have been a hardware issue. I forgot to
 mention that this Dell PWS 390 was then running BIOS 2.3.0 and logging
   kernel: mtrr: type mismatch for d000,800 old: write-back new: 
 write-combining
 on a regular basis. I have since upgraded to BIOS 2.5.0, which got rid
 of the MTRR warnings.
   

I don't think this could explain such a crash anyway.

Brice




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Processed: Re: Bug#469642: Signal 11 at libGLcore.so(_mesa_update_draw_buffer_bounds+0x59)

2008-03-11 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 tags 469642 +moreinfo
Bug#469642: Signal 11 at libGLcore.so(_mesa_update_draw_buffer_bounds+0x59)
There were no tags set.
Tags added: moreinfo

 thank you
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#469642: Signal 11 at libGLcore.so(_mesa_update_draw_buffer_bounds+0x59)

2008-03-10 Thread Brice Goglin
On Thu, Mar 06, 2008 at 11:35:53AM +0100, Sergio Gelato wrote:
 Package: xserver-xorg-core
 Version: 2:1.1.1-21etch4
 
 The following backtrace has been seen repeatedly on a Dell PWS 390
 running in amd64 mode with an nVidia NV44 (Quadro NVS 285) card using 
 the nv driver. Matlab 7.5.0 seems particularly prone to triggering the 
 problem, but it isn't the only culprit.
 
 --
 Backtrace:
 0: /usr/bin/X(xf86SigHandler+0x6d) [0x4720bd]
 1: /lib/libc.so.6 [0x2adf4b6a3110]
 2: 
 /usr/lib/xorg/modules/extensions/libGLcore.so(_mesa_update_draw_buffer_bounds+0x59)
  [0x2adf55fa0d89]
 3: /usr/lib/xorg/modules/extensions/libGLcore.so [0x2adf5609514d]
 4: /usr/lib/xorg/modules/extensions/libglx.so(DoMakeCurrent+0x511) 
 [0x2adf4c237ad1]
 5: /usr/lib/xorg/modules/extensions/libglx.so [0x2adf4c23a2b4]
 6: /usr/bin/X(Dispatch+0x1b9) [0x448179]
 7: /usr/bin/X(main+0x44d) [0x430f9d]
 8: /lib/libc.so.6(__libc_start_main+0xda) [0x2adf4b6904ca]
 9: /usr/bin/X(FontFileCompleteXLFD+0xa2) [0x43029a]

(this may be similar to #414307 but I can't reproduce it anymore with 
2:1.1.1-21etch4)

The crash is in the Mesa built-in the server, and this mesa 6.5.1 is very old.
So please try to reproduce with a more recent Xserver built against a recent 
Mesa.
xserver-xorg-core from testing would be much better already.

Brice



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#469642: Signal 11 at libGLcore.so(_mesa_update_draw_buffer_bounds+0x59)

2008-03-10 Thread Sergio Gelato
* Brice Goglin [2008-03-10 19:51:06 +0100]:
 The crash is in the Mesa built-in the server, and this mesa 6.5.1 is very old.
 So please try to reproduce with a more recent Xserver built against a recent 
 Mesa.
 xserver-xorg-core from testing would be much better already.

Sorry, but the affected computer is in production and not available for
further testing. I (reluctantly) switched to the proprietary nvidia
driver as a workaround, and that worked out to the user's satisfaction.

As with all problems that have only been observed on one machine, one
wonders whether it might have been a hardware issue. I forgot to
mention that this Dell PWS 390 was then running BIOS 2.3.0 and logging
kernel: mtrr: type mismatch for d000,800 old: write-back new: 
write-combining
on a regular basis. I have since upgraded to BIOS 2.5.0, which got rid
of the MTRR warnings.

Under the circumstances I don't expect you to spend much time
investigating this bug report, but I thought I'd document my findings
anyway for the sake of the next person who runs into the same symptoms.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#469642: Signal 11 at libGLcore.so(_mesa_update_draw_buffer_bounds+0x59)

2008-03-06 Thread Sergio Gelato
Package: xserver-xorg-core
Version: 2:1.1.1-21etch4

The following backtrace has been seen repeatedly on a Dell PWS 390
running in amd64 mode with an nVidia NV44 (Quadro NVS 285) card using 
the nv driver. Matlab 7.5.0 seems particularly prone to triggering the 
problem, but it isn't the only culprit.

--
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6d) [0x4720bd]
1: /lib/libc.so.6 [0x2adf4b6a3110]
2: 
/usr/lib/xorg/modules/extensions/libGLcore.so(_mesa_update_draw_buffer_bounds+0x59)
 [0x2adf55fa0d89]
3: /usr/lib/xorg/modules/extensions/libGLcore.so [0x2adf5609514d]
4: /usr/lib/xorg/modules/extensions/libglx.so(DoMakeCurrent+0x511) 
[0x2adf4c237ad1]
5: /usr/lib/xorg/modules/extensions/libglx.so [0x2adf4c23a2b4]
6: /usr/bin/X(Dispatch+0x1b9) [0x448179]
7: /usr/bin/X(main+0x44d) [0x430f9d]
8: /lib/libc.so.6(__libc_start_main+0xda) [0x2adf4b6904ca]
9: /usr/bin/X(FontFileCompleteXLFD+0xa2) [0x43029a]

Fatal server error:
Caught signal 11.  Server aborting
---

A similar backtrace was reported on 2007-02-05 by Ed Schofield; see
https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/71913/comments/4
Unfortunately, that Launchpad entry has collected a lot of possibly
unrelated backtraces from various people; the one of interest here
isn't its main focus.

A look at a disassembly of _mesa_update_draw_buffer_bounds indicates
that the crash is actually in the inlined function update_framebuffer_size()
and results from some Attachment's Renderbuffer pointing to a stray
memory location. The fault occurs while dereferencing rb-Width, so
rb is non-NULL (there is an explicit test for this in the code)
and rb+0x10 is pointing outside valid memory. haveSize appears to be
false, so this must be the first Attachment with a non-NULL Renderbuffer.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]