OoO En ce début d'après-midi ensoleillé du mercredi 09 novembre 2011, vers 15:31, "Fabien C." <6pfb3fk2kums...@jetable.org> disait :
> * This bug also occurs on chromium 14 backported on Squeeze. > Michael Gilbert and I have been making unofficial backports of > Chromium (for quite a long time), but since version 14, we couldn't > get it to work, because of the "Aw, Snap!" problem described here. > However the browser was working with the --single-process or --no-sandbox > options. > Then, I guess this bug does not come from chromium 15, but was already > present in some way in version 14. > We tried to identify the bug without success due to a lack of time and/or > knowledge. > You can follow our discussion here : > http://lists.alioth.debian.org/pipermail/pkg-chromium-maint/2011-October/001508.html This thread contains some interesting stuff. There seems to be a lot of way to debug Chromium. --wait-for-debugger-children=render does not seem to work. --wait-for-debugger only waits a debugger for the browser, not for the renderer. Moreover, the documentation says it will wait 60 seconds. This is not true on Linux. It waits for a USR1 signal. `chromium --renderer-startup-dialog --allow-sandbox-debugging` seems to give some interesting results. We don't have a dialog box and the given PID is not really a PID but it is possible to find the appropriate processes with `ps` and attach to them with gdb. Then, unpause by sending a USR1 signal and you can start to debug. Unfortunately, in my case, I get a lot of `Program received signal SIGTRAP, Trace/breakpoint trap.`. If I try to ignore them with `handle SIGTRAP nostop noprint`, it seems to loop forever. I am never able to get back into the renderer code. Maybe someone more experienced with debugging C++ code could take the lead from here? -- Vincent Bernat ☯ http://vincent.bernat.im Make sure every module hides something. - The Elements of Programming Style (Kernighan & Plauger)
pgpv0EllO0Y66.pgp
Description: PGP signature
