On Mon, Aug 29, 2011 at 10:51 PM, Christopher Michael <cpmicha...@comcast.net> wrote: > On 08/29/2011 02:20 PM, Tom Hacohen wrote: >> On 29/08/11 19:06, Christopher Michael wrote: >>> gdb attach<pid> >>> (gdb) set unwindonsignal on >>> (gdb) call eina_stringshare_del(234234) >>> >>> works in that it makes it possible to debug using gdb like you are >>> (calling efl functions inside gdb). >>> >>> As far as the alert dialog working (restart/exit), we know it works when >>> E receives the signal from modules, etc. The problem you are >>> experiencing could be from gdb catching the signals instead of E, or it >>> could be due to xcb being threaded...not entirely sure which one, but >>> the alert code itself does work. >>> >>> If you compare the changes to the old alert code and this version, you >>> will see that there is not much difference really (aside from xcb doing >>> the dialog drawing) so I am not sure that This even worked in the old >>> version. If it did work previously, then it could just be the threaded >>> nature of xcb which is the problem, but as such there is not much can be >>> done about that...I can't change xcb's threaded nature ;) >>> >>> I don't know enough about what gdb is doing wrt signals to dig much >>> deeper into this. Do we have any gdb gurus that could help ?? >> >> Sorry, I was'nt clear: call eina_stringshare_del like you did, *detach >> gdb* and then press F1/press the button. And still, it fails... This has >> nothing to do with gdb, it just fails, so no need for gdb gurus. >> >> Please check that out. >> >> -- >> Tom. >> > > Sadly, there is not much I can do here :( I keep trying your method of > reproduction, but I cannot get (or see) any meaningful reason why this > is failing. The only thing I did see that was curious was: > > When running like this (using gdb to call efl functions and produce an > error), the e_signal functions do get called, which in turn does call > e_alert_main (thus the white box), BUT what I see happening is that gdb > is intercepting the kill(e_pid, SIGUSR2). This causes major problems !!! > as now E itself is stuck in pause thus when e_alert_main tries to send > the 'restart' command, E never gets to processes it because it (E) is > still stuck in pause because gdb intercepted the sigusr2. > > I am not sure what (if anything) can be done wrt this. The best advise I > can give would be to use the 'set unwindonsignal on' as this allows E to > receive the SIGUSR2 and thus continue with the restart.
If that's the issue, why don't we simplify the code of e_alert by directly using fork/exec/waitpid and taking the exit code of enlightenment_alert as the order. Exit code of 0 mean exit and 1 restart. That would simplify a lot the code path of both part (something that make sense when you are already in bad shape). -- Cedric BAIL ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
