On 08/29/2011 05:08 PM, Cedric BAIL wrote: > 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).
I would not be against that as an option :) It does make more sense. If I can find some time soon, I'll go ahead and do that...if not, it may have to wait a little while. dh ------------------------------------------------------------------------------ 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
