On 05/04/2010 02:40 PM, Jamey Sharp wrote:
On Tue, May 4, 2010 at 6:54 AM, The Wanderer <[email protected]>
wrote:
I'm familiar with doing that (well, 'gdb foo' and 'run -v quux'),
but I could have sworn that last time I tried it on a failed
assertion, the 'bt full' returned no information, because the
running program had already exited because of the failed assertion.
No, assert calls abort(), which kills the current process with
SIGABRT, which GDB traps before the process actually exits.
Of course if this application is forking, it can be quite tricky to
get gdb attached to the process that actually dies. It may be easier
to run `ulimit -c unlimited` to enable core dumps, then let the
application die, then use `gdb -c` to inspect the coredump.
I tried that, both with running the shell-script wrapper and with
running its commands by hand (just in case the ulimit setting was
getting lost somewhere), and no core file seems to have been produced in
any obvious location. I've checked /tmp, the current directory, and the
directory with the executable being run by Wine, with no luck.
I tried just running Wine under gdb, in case it would in fact catch the
correct process; it did catch the signal after the assert, but 'bt full'
just reported a series of
#0 0x12345678 in ?? ()
No symbol table info available
which obviously isn't very useful.
Hey, does `glxinfo` assert-fail for you?
No. The only thing which assert-fails for me, that I've tried so far, is
Wine, and that only (as far as I can tell) when trying to use OpenGL.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
