Jonathan Nieder wrote:
> g_nss_singleton.Get();
> std::cerr << "This is not printed.\n";
> }
[...]
> The next step is to dig into the NSSInitSingleton constructor,
> presumably.
It dies in here:
| NSSInitSingleton()
| : opencryptoki_module_(NULL),
| software
Hi,
Vincent Bernat wrote:
> #if defined(OS_POSIX) && !defined(OS_MACOSX)
> RenderProcessImpl render_process;
> render_process.set_main_thread(new RenderThread());
> #endif
>
> Here, I am greeted with:
> waiting for new child: No child processes.
Yes, I get the same thing. Not sure wha
OoO La nuit ayant déjà recouvert d'encre ce jour du jeudi 10 novembre
2011, vers 23:17, je disais:
> 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 d
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
* 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 wi
5 matches
Mail list logo
