Bug 3289

Evne when building with -g and Dll modules, I cannot get more information 
from gdb.

The stack corrupt message could be due to a gdb problem with -f PIC and -O2 on
powerpc. I wonder if other people have problems with magicpoint on xorg.

I also experience problems with Magicpoint and X.Org, but am not 100% sure where
they originate. It _used_ to work just fine, but after doing a dist-upgrade to
sarge last weekend, magicpoint now dies with the message:

 X Error of failed request:  BadMatch (invalid parameter attributes)
   Major opcode of failed request:  75 (X_PolyText16)
   Serial number of failed request:  604
   Current serial number in output stream:  605

FYI -- installed versions:
ii  xorg-common              6.8.1-0.4                X Window System (X.Org)
infrastructure
ii  xorg-driver-synaptics    0.13.6-2                 Synaptics TouchPad driver
for X.Org server
ii  xserver-xorg             6.8.1-0.4                the X.Org X server
ii  mgp                      1.11b-2                  MagicPoint- an X11 based
presentation tool

(In reply to comment #2)
> The stack corrupt message could be due to a gdb problem with -f PIC and -O2 on
> powerpc. I wonder if other people have problems with magicpoint on xorg.

What if you build with 'makeg' instead of 'make'? That should add -g and remove -O2.

Michel: Thanks for the hint, it seems that
http://wiki.x.org/wiki/DebuggingTheXserver has mislet me into believing
that seeing the option in host.def would be fine, but I just rechecked
and found out that I actually did not use "-g" when building the version,
so now I try makeg and the build roles. Can you update the wiki?

Now really rebuild xorg cvs from today (20050517) and starting mgp
gives me the following message now:

X Error of failed request:  BadAlloc (insufficient resources for operation)
Major opcode of failed request:  78 (X_CreateColormap)
Serial number of failed request:  9
Current serial number in output stream:  10

In my next attempts I get the crash again, so maybe xorg is corrupting its own
stack?

Created attachment 2694 [details]
gdb Debugging session

Here is a gdb debugging session. gdb itself seems to be able to produce
backtraces
to a certain extend.

My tests are on cvs_head now.

Please also attach the X server configuration and log files. In particular, I'm
curious whether the Composite extension is enabled?

Created attachment 2762 [details]
Typical log file when crashing.

Created attachment 2763 [details]
One xorg.conf that I can see the crash with.

Note that I want to have an external display working,
thus the larger virtual screen. I did see the crash without external display,
too.

Composite currently is enabled.
I will try without next.

Note that I do start this server as extra server on a free screen terminal
so I can keep my production XFree 4.3. running in parallel. Could this make 
a difference? (I believe I tested it without Xfree running and saw no change in
the behaviour.)

Heureka!
Disabling Composite was the right thing to do!
I can use mgp now!  :)
Michel: Thanks again for the hint!

Thus I am changing the title and the severity of the bug.
Is that fine now?

Just a note that I failed to reproduce this issue with "mgp -g 400x300
/usr/X11R6/share/doc/mgp/sample/sample.mgp".  CVS head as of around 2005-09-28
and magicpoint 1.11b, composite enabled, XAA.

Need more info on how to reproduce, or a good stack trace from gdb.  Also, does
the problem still exist with current xserver from git?  I just fixed a crash
that may occur with XAA and Composite.

(In reply to comment #16) 
> Need more info on how to reproduce, or a good stack trace from gdb.   
 
My machine is a powerpc (big endian) this could be a major difference. 
The problem with gdb is, that the version I got with Debian Sarge 
does not work proberly regarding stack traces, so it is a bit away for me 
to get a better backtrace. 
 
> Also, does 
> the problem still exist with current xserver from git?  I just fixed a crash 
> that may occur with XAA and Composite. 
 
Unfortunatley it might take me a while until I can do 
a new test compile and find out if the bug is still there. 
I am currently running without composite which makes it non-critical for me. 
Thanks a lot for the response, the hint about the potential fix and for 
contributing to Free Software in general! 
 
 

Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.