> So far, I've seen 2 SEGVs and no coredumps.
Off topic... I'm not on my linux box right now, but IIRC (I may well not,
please correct any badness):
ulimit -c 2048 && xinit
you need to use ulimit to set your limits - core dumps are probably limited to
0, ie they don't get made. "ulimit -c 2048" will limit core dumps to 2MB. I
think they'll be dumped into the folder that xinit was run in. Then run "gdb
/usr/bin/enlightenment <corefile>", where <corefile> is the dump - on my system
it's just named "core", but I think it can also be called "core.<process-ID>"
or "enlightenment.core", or somesuch.
Also, if your compiler supports it, -fstack-protector in the CFLAGS will stop
the stack becoming corrupt on a segv, which makes debugging much nicer. I'd
guess that like with all CFLAGS, there are great flamewars over it's use, and
I've probably offended someone by suggesting it :(
I find cores more useful than gdb <program>, because in threaded apps cores are
always dumped, but using gdb on threaded apps is painful. Also, with the
no-core approach you need to run all your apps in gdb just in case they crash,
whereas cores are automatic.
-- Shish
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
