On Mon, Aug 29, 2011 at 11:17 PM, Christopher Michael <cpmicha...@comcast.net> wrote: > 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.
Ok, I just experienced the White Death Box and I confirm it's borken ! If you don't have the time to fix it, tell me, the code look pretty simple to do the modification and I can do it quickly as it's a little bit annoying :-) -- 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
