So far, I've seen 2 SEGVs and no coredumps. The first seemed to be because I was using the menus having set off a menu regeneration.
The second was while I was trying to figure out what was going on
with my icon boxes (it turned out I had three stacked in the bottom
left, after a weird problem last week with the old version I'd built
myself and a reboot I didn't initiate - not a Solaris fault, a man
came around to do our annual power checks while I was on holiday, so
they shutdown my desktop dirty). Everything else seems fine, and no
other crashes so far - but since the last version was incredibly
stable, these two crashes are disturbing.
OK, there are problems with multiple iconboxes If you have directions to reproduce the segv's, please let me know.
I also note that on attempting a restart, I get a dialogue wanting to
edit my .xinitrc, and even if I can click to get rid of it, it just hangs on the spinning watch. This was fixed a while back, but seems
to have come back? It was only ever a problem on Solaris, and some
checks for whether or not there really was another WM running were
added. I see 3 processes on my box, because I have 2 screens off two
separate (and different) graphics cards in here.
I have tried quite a lot of killing and restarting without being able to reproduce this. However, when E is restarted after a segv, this happens from within a signal handler and I can imagine there could be some Solaris/Linux differences here. I have made some minor changes to the signal handling setup code that may cure the problem.
The lack of cores is a pain - I'll try to force one if it SEGVs again.
Yes, a nice core dump is more useful than the GSOD. I usually run E from gdb in a VT. I guess you don't have a similar possibility? I have added the feature that if the env var EDBUG_COREDUMP is set, the segv and similar signals are not caught by E. Maybe this can help?
/Kim
Sorry if this aleady got posted, I'm having trouble with my ISP.
-------------------------------------------------------
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
