Debian Bug report logs - #647992
[squeeze-backports] chromium: unrecoverable Aw, Snap! on start up

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Mattia Monga <monga@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: chromium: unrecoverable Aw, Snap! on start up

Date: Tue, 08 Nov 2011 09:26:28 +0100

Package: chromium
Version: 15.0.874.106~r107270-1
Severity: grave
Justification: renders package unusable

Chromium starts with a Aw, Snap! page and it is stuck on that. 

Using an empty user-data-dir doesn't help. I managed to get it working by using the --single-process option. Since I get a

[5720:5735:3873153110:ERROR:proxy_service_factory.cc(66)] Cannot use V8 Proxy resolver in single process mode.

I believe the problem is related to V8



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages chromium depends on:
ii  chromium-inspector  15.0.874.106~r107270-1 
ii  libasound2          1.0.24.1-4             
ii  libavcodec53        4:0.7.2-1+b1           
ii  libavformat53       4:0.7.2-1+b1           
ii  libavutil51         4:0.7.2-1+b1           
ii  libbz2-1.0          1.0.5-7                
ii  libc6               2.13-21                
ii  libcairo2           1.10.2-6.1             
ii  libcups2            1.5.0-10               
ii  libdbus-1-3         1.4.16-1               
ii  libdbus-glib-1-2    0.98-1                 
ii  libevent-1.4-2      1.4.14b-stable-1       
ii  libexpat1           2.0.1-7.2              
ii  libflac8            1.2.1-6                
ii  libfontconfig1      2.8.0-3                
ii  libfreetype6        2.4.7-2                
ii  libgcc1             1:4.6.2-4              
ii  libgconf2-4         2.32.4-1               
ii  libgcrypt11         1.5.0-3                
ii  libgdk-pixbuf2.0-0  2.24.0-1               
ii  libglib2.0-0        2.30.1-2               
ii  libgtk2.0-0         2.24.7-1               
ii  libjpeg8            8c-2                   
ii  libnspr4-0d         4.8.9-1                
ii  libnss3-1d          3.13.1.with.ckbi.1.88-1
ii  libpango1.0-0       1.29.4-2               
ii  libpng12-0          1.2.46-3               
ii  libspeex1           1.2~rc1-1              
ii  libstdc++6          4.6.2-4                
ii  libvpx0             0.9.7.p1-2             
ii  libwebp2            0.1.3-1                
ii  libx11-6            2:1.4.4-2              
ii  libxext6            2:1.3.0-3              
ii  libxml2             2.7.8.dfsg-5           
ii  libxrender1         1:0.9.6-2              
ii  libxslt1.1          1.1.26-8               
ii  libxss1             1:1.2.1-2              
ii  xdg-utils           1.1.0~rc1-2            
ii  zlib1g              1:1.2.3.4.dfsg-3       

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-l10n  <none>

-- no debconf information

Message #18 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 647992@bugs.debian.org

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Tue, 8 Nov 2011 13:02:13 -0600

merge 647992 648018 648035
quit

Mattia Monga wrote:

> Using an empty user-data-dir doesn't help. I managed to get it working by
> using the --single-process option.

Yep, that's inconvenient.

Backtrace: [1]

It seems that the segfault is happening somewhere within
BalloonViewHost::UpdateActualSize().

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=gdb-chromium.txt;att=1;bug=648031

Message #27 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Hideki Yamane <henrich@debian.org>

Cc: 647992@bugs.debian.org

Subject: Re: chromium crashes

Date: Wed, 9 Nov 2011 02:51:56 -0600

Hi,

Hideki Yamane wrote:

>  After upgrading to 15.0.874.106~r107270-1, chromium cannot show any pages
>  (setting, local and remote).

Yep.

>  I'll attach backtrace as http://wiki.debian.org/Chromium/Debugging instructs.

Nice!  How did you do that? :)

When I tried to get a backtrace here, I have no luck:

chromium -g::
	Renderer dies, chrome stays alive --- no backtrace.

chromium -g --temp-profile --single-process::
	Renderer doesn't die.

chromium --temp-profile \
  --renderer-cmd-prefix='xterm -title renderer -e gdb --args'::
	Renderer doesn't die.

chromium --temp-profile --renderer-cmd-prefix='xterm -e'::
	Renderer doesn't die.

chromium --temp-profile --renderer-cmd-prefix=''::
	Renderer dies, chrome stays alive --- no backtrace.

Which makes sense: as the upstream LinuxDebugging doc says,

| Note: using the --renderer-cmd-prefix option bypasses the zygote
| launcher, so the renderers won't be sandboxed. It is generally not an
| issue, except when you are trying to debug interactions with the
| sandbox.

I'm just surprised it was possible to easily do that without
artificially inserting a sleep() somewhere.

> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff8fb02a0 in ?? ()
> (gdb) bt
> #0  0x00007ffff8fb02a0 in ?? ()
> #1  0x00007ffff5097971 in BalloonViewHost::UpdateActualSize (this=0x7ffff8cb60e0, new_size=...) at chrome/browser/ui/gtk/notifications/balloon_view_host_gtk.cc:22
[...]

Would it be possible to get a full backtrace ("bt full") and
disassembly in the top frame near the ip at the time of the crash
("disassemble")?

Thanks much,
Jonathan

Message #32 received at 647992@bugs.debian.org (full text, mbox, reply):

From: "Fabien C." <6pfb3fk2kumsw4t@jetable.org>

To: 647992@bugs.debian.org

Subject: same bug on chromium 14 backport on squeeze

Date: Wed, 09 Nov 2011 15:31:12 +0100

* 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 

Fab 

Message #37 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Hideki Yamane <henrich@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: chromium crashes

Date: Thu, 10 Nov 2011 01:13:34 +0900

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

On Wed, 9 Nov 2011 02:51:56 -0600
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Nice!  How did you do that? :)

 Just did "chromium-browser --debug". Maybe because I've installed silver bird 
 as extension and it would fortunately ;) pop-up for notification, plus, I uses
 slow CPU (AMD C-50) on laptop, then it causes segfault (just wild guess). 


> Would it be possible to get a full backtrace ("bt full") and
> disassembly in the top frame near the ip at the time of the crash
> ("disassemble")?

 This is my first bt time, so I don't fully understand your instructions(sorry)
 but just "bt full" is fine. Anyway I'll attach second one.


- -- 
Regards,

 Hideki Yamane     henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCgAGBQJOuqavAAoJEF0yjQgqqrFAHLIP/1/mFxa+zBEXtVMb0HLbliJ+
mWH1VZYHlN8tGNlZTYeJ7a1nt1sLCTEcCTJ7mw6W5j6EjaE/g4eK6E9G3wVVufhy
n8Z5a9XHweG0DfevGbc3YFCp3U4TVgXU+BkrNmPZjsGi300qpbbNsKRQZ8ljz/y/
xipPY3Xp3+1FCbFizY3GQ3zEHCbw9r3i7RteSDqA9RkcwIt7PBlGwT0xHtJMlYiz
S3whFuPTYLlRBJM89IGnttH0xtpIa1JxD6Cin7NXExKhfvspeqIfA5yErymsbqy2
Ds8cyatOhccF1bamSsc5vBtVbYqnUUPBh9Z7TgDYWlZtKJf+NdkhliYrRKzvN1vc
S2Kbh7AkmWOH54rggIRIOjit8LMB0gFIKS4fVh8134v+2nPMoZcEBuePQgQHn54c
U8aR3PdARdobZG9mZxczkwdVOGAvfyF+4c8aMqPlruYFke6OZhnCo+iWVTZ0m9mH
an9jKntR/+ADElcXRgIFhxWQi2yEWqhIaY5KUqv56NTCuDf10QFNQQYl7OYONcVy
GyNKAyiMvBRiAiE8SBZIBTl1VVxyGkvtVNjTn5iKbUETazbC46GABubylrLKL9HP
9/tj1aJwPuMW89r0jEb18MpIKg09OHyWRH8UzRjugO3O7+vo03a1vdq/CqqnZRjB
uKzYIYSK65mCunOfVInR
=L6u4
-----END PGP SIGNATURE-----

[gdb-chromium.txt (text/plain, attachment)]

Message #42 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 647992@bugs.debian.org

Subject: Re: chromium crashes

Date: Wed, 9 Nov 2011 14:33:54 -0600

Jonathan Nieder wrote:

> chromium --temp-profile --renderer-cmd-prefix='xterm -e'::
> 	Renderer doesn't die.
>
> chromium --temp-profile --renderer-cmd-prefix=''::
> 	Renderer dies, chrome stays alive --- no backtrace.
>
> Which makes sense: as the upstream LinuxDebugging doc says,

More notes!  The renderer request is sent to and successfully served
by the zygote[1]:

| forking request "/proc/self/exe" "--type=renderer" "--lang=en-US" "--force-fieldtest=ConnCountImpact/conn_count_6/ConnnectBackupJobs/ConnectBackupJobsEnabled/DnsImpact/default_enabled_prefetch/DnsParallelism/parallel_default/GlobalSdch/global_enable_sdch/IdleSktToImpact/idle_timeout_10/Prefetch/ContentPrefetchPrerender2/ProxyConnectionImpact/proxy_connections_32/SpdyCwnd/cwndMin16/SpdyImpact/npn_with_spdy/SuggestHostPrefix/Default_Prefix/WarmSocketImpact/warmest_socket/" "--disable-client-side-phishing-detection" "--enable-click-to-play" "--channel=547.0x7fcb143bc000.1339080197" 
| this is it --- sending requset
| reply is pid 566

Successfully, except that the forked child dies.

Renderer doesn't die with "--no-sandbox", alas.  Next attempt:

 $ chromium --temp-profile --zygote-cmd-prefix='\
/usr/bin/xterm -title zygote -e gdb --eval-command=run --args' \
	--log-level=0 --enable-logging=stderr --v=1
 [1507:1507:243277707209:FATAL:zygote_host_linux.cc(198)] Check failed: pid_ > 0. Did not find zygote process (using sandbox binary /usr/lib/chromium/chromium-sandbox)
 Aborted (core dumped)

Maybe gdb takes too long to load the debugging symbols and the
"chromium-sandbox --find-inode" is not able to find it.

[1] http://code.google.com/p/chromium/wiki/LinuxZygote

$ uname -a
Linux elie 3.1.0-1-amd64 #1 SMP Thu Nov 3 19:35:59 UTC 2011 x86_64 GNU/Linux

Message #47 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jean Lorchat <jean@iijlab.net>

To: 647992@bugs.debian.org

Subject: more info ?

Date: Thu, 10 Nov 2011 09:13:35 +0900

Hi,

I also have seen this issue (on a wheezy/sid) and noticed that it 
happened since the machine was last updated. At that time, chromium was 
held back because it needed to install a new dependency, libwebp2, that 
the system was lacking.

Maybe a coincidence, maybe not (but it hints at the same problem than 
monga's earlier message).

Cheers,
Jean

Message #52 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: "Fabien C." <6pfb3fk2kumsw4t@jetable.org>

Cc: 647992@bugs.debian.org

Subject: Re: same bug on chromium 14 backport on squeeze

Date: Thu, 10 Nov 2011 23:17:17 +0100

[Message part 1 (text/plain, inline)]

OoO En  ce début d'après-midi  ensoleillé du mercredi 09  novembre 2011,
vers 15:31, "Fabien C." <6pfb3fk2kumsw4t@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)

[Message part 2 (application/pgp-signature, inline)]

Message #57 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: "Fabien C." <6pfb3fk2kumsw4t@jetable.org>

Cc: 647992@bugs.debian.org

Subject: Re: same bug on chromium 14 backport on squeeze

Date: Thu, 10 Nov 2011 23:27:14 +0100

[Message part 1 (text/plain, inline)]

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 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?

I have tried a second time and got more luck. Now I am able to step into
RendererMain() until the following code:

#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.

Dunno what to do.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Replace repetitive expressions by calls to a common function.
            - The Elements of Programming Style (Kernighan & Plauger)

[Message part 2 (application/pgp-signature, inline)]

Message #62 received at 647992@bugs.debian.org (full text, mbox, reply):

From: jidanni@jidanni.org

To: 647992@bugs.debian.org

Subject: me too

Date: Sun, 13 Nov 2011 19:49:26 +0800

whatabunchofjunk

Message #67 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Vincent Bernat <bernat@debian.org>

Cc: 647992@bugs.debian.org, "Fabien C." <6pfb3fk2kumsw4t@jetable.org>

Subject: Re: same bug on chromium 14 backport on squeeze

Date: Sun, 13 Nov 2011 18:06:42 -0600

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 what the cause is.

> Dunno what to do.

Adding "#include <iostream>" to the top of relevant files and putting

	std::cerr << "here is some state: " << state << "\n";

at points of interest works.  And it's kind of pleasant --- it forces
one to stare at code between runs.

No conclusions yet.  Looks like the failure happens in
src/crypto/nss_util.cc, function EnsureNSSInit():

	void EnsureNSSInit() {
	  // Initializing SSL causes us to do blocking IO.
	  // Temporarily allow it until we fix
	  //   http://code.google.com/p/chromium/issues/detail?id=59847
	  base::ThreadRestrictions::ScopedAllowIO allow_io;

	  std::cerr << "This is printed.\n";

	  g_nss_singleton.Get();

	  std::cerr << "This is not printed.\n";
	}

g_nss_singleton is declared as follows:

	base::LazyInstance<NSSInitSingleton,
			   base::LeakyLazyInstanceTraits<NSSInitSingleton> >
	    g_nss_singleton(base::LINKER_INITIALIZED);

The next step is to dig into the NSSInitSingleton constructor,
presumably.

Message #72 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Vincent Bernat <bernat@debian.org>

Cc: 647992@bugs.debian.org, "Fabien C." <6pfb3fk2kumsw4t@jetable.org>

Subject: Re: same bug on chromium 14 backport on squeeze

Date: Sun, 13 Nov 2011 19:57:30 -0600

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_slot_(NULL),
|         test_slot_(NULL),
|         tpm_slot_(NULL),
|         root_(NULL),
|         chromeos_user_logged_in_(false) {
[...]
|     bool nodb_init = force_nodb_init_;
|
| #if !defined(USE_NSS)
|     // Use the system certificate store, so initialize NSS without database.
|     nodb_init = true;
| #endif
| 
|     if (nodb_init) {
|       std::cerr << "This is printed.\n";
|       status = NSS_NoDB_Init(NULL);
|
|       std::cerr << "This is not printed.\n";

Message #77 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Sebastian Reichel <sre@debian.org>

To: 647992@bugs.debian.org

Subject: chromium 14 broken with libnss3-1d from sid

Date: Tue, 15 Nov 2011 13:15:10 +0100

[Message part 1 (text/plain, inline)]

Hi,

I noticed, that Chromium 14 has the same problem when libnss3-1d
from sid (3.13.1.with.ckbi.1.88-1) is used (at least the symptoms
are the same). Installing libnss3-1d from testing (3.12.11-3) it
works as expected.

Chromium 15 doesn't work with either of them, though.

-- Sebastian

[signature.asc (application/pgp-signature, inline)]

Message #82 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: libnss3-1d@packages.debian.org

Cc: Sebastian Reichel <sre@debian.org>, 647992@bugs.debian.org

Subject: Re: chromium 14 broken with libnss3-1d from sid

Date: Tue, 15 Nov 2011 16:36:31 -0600

Hi Mike et al,

Chromium (15)'s renderer processes are all dying here:

	NSSInitSingleton()
	    : opencryptoki_module_(NULL),
	      software_slot_(NULL),
	      test_slot_(NULL),
	      tpm_slot_(NULL),
	      root_(NULL),
	      chromeos_user_logged_in_(false) {
	...
	  if (nodb_init) {
	    status = NSS_NoDB_Init(NULL); <---- this dies somehow

Sebastian Reichel wrote:

> I noticed, that Chromium 14 has the same problem when libnss3-1d
> from sid (3.13.1.with.ckbi.1.88-1) is used (at least the symptoms
> are the same). Installing libnss3-1d from testing (3.12.11-3) it
> works as expected.

Does this sound believable?  Any ideas for tracking it down?

Thanks,
Jonathan

Message #87 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: libnss3-1d@packages.debian.org, Sebastian Reichel <sre@debian.org>, 647992@bugs.debian.org

Subject: Re: chromium 14 broken with libnss3-1d from sid

Date: Tue, 15 Nov 2011 23:49:16 +0100

On Tue, Nov 15, 2011 at 04:36:31PM -0600, Jonathan Nieder wrote:
> Hi Mike et al,
> 
> Chromium (15)'s renderer processes are all dying here:
> 
> 	NSSInitSingleton()
> 	    : opencryptoki_module_(NULL),
> 	      software_slot_(NULL),
> 	      test_slot_(NULL),
> 	      tpm_slot_(NULL),
> 	      root_(NULL),
> 	      chromeos_user_logged_in_(false) {
> 	...
> 	  if (nodb_init) {
> 	    status = NSS_NoDB_Init(NULL); <---- this dies somehow

This dies how? Do you have a backtrace?

Mike

Message #92 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Mike Hommey <mh@glandium.org>

Cc: libnss3-1d@packages.debian.org, Sebastian Reichel <sre@debian.org>, 647992@bugs.debian.org

Subject: Re: chromium 14 broken with libnss3-1d from sid

Date: Tue, 15 Nov 2011 17:13:38 -0600

Mike Hommey wrote:
> On Tue, Nov 15, 2011 at 04:36:31PM -0600, Jonathan Nieder wrote:

>> Chromium (15)'s renderer processes are all dying here:
>> 
>> 	NSSInitSingleton()
>> 	    : opencryptoki_module_(NULL),
>> 	      software_slot_(NULL),
>> 	      test_slot_(NULL),
>> 	      tpm_slot_(NULL),
>> 	      root_(NULL),
>> 	      chromeos_user_logged_in_(false) {
>> 	...
>> 	  if (nodb_init) {
>> 	    status = NSS_NoDB_Init(NULL); <---- this dies somehow
>
> This dies how? Do you have a backtrace?

No backtrace.  One can reproduce it by installing chromium-browser
from sid and running it.

Expected result: shows some page
Actual result: "Aw, snap. Something went wrong while rendering this
page".

The usual methods for debugging chromium don't work here.  The
renderer has to be forked from the zygote[1] to reproduce it, or else
chromium frustratingly just works fine, so we can't use
"--renderer-cmd-prefix='xterm -e gdb --args'" or --single-process.
Some people had success using some magic like
"--renderer-startup-dialog --allow-sandbox-debugging", but not me.
All I know is that changing the source to say

	if (nodb_init) {
	  std::cerr << "about to call NSS_NoDB_Init(NULL)\n";
	  status = NSS_NoDB_Init(NULL);
	  std::cerr << "finished NSS_NoDB_Init(NULL)\n";

causes the "about to call" line to be printed, but the "finished" line
not to.

[1] http://code.google.com/p/chromium/wiki/LinuxZygote

Message #97 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Mike Hommey <mh@glandium.org>

Cc: libnss3-1d@packages.debian.org, Sebastian Reichel <sre@debian.org>, 647992@bugs.debian.org

Subject: Re: chromium 14 broken with libnss3-1d from sid

Date: Tue, 15 Nov 2011 19:11:16 -0600

Jonathan Nieder wrote:

> All I know is that changing the source to say
>
> 	if (nodb_init) {
> 	  std::cerr << "about to call NSS_NoDB_Init(NULL)\n";
> 	  status = NSS_NoDB_Init(NULL);
> 	  std::cerr << "finished NSS_NoDB_Init(NULL)\n";
>
> causes the "about to call" line to be printed, but the "finished" line
> not to.

On the NSS side, in
mozilla/security/nss/lib/pk11wrap/pk11load.c::secmod_ModuleInit():

	    }

	    fprintf(stderr, "about to call C_Initialize\n");
	    crv = PK11_GETTAB(mod)->C_Initialize(pInitArgs);
	    fprintf(stderr, "finished C_Initialize\n");

	    if (CKR_CRYPTOKI_ALREADY_INITIALIZED == crv) {

causes the "about to call" line to be printed, but the "finished" line
not to.

This is the second time secmod_LoadPKCS11Module() is called.  The
first time, it returns early (if (mod->moduleDBOnly) { ... return
SECSuccess; }).

The renderer process is sandboxed[1], which means that (among other
things) I think it lives in its own PID namespace, and at some point
later it will get chrooted to avoid filesystem access.  Here's what
the caller (the ChromeRenderProcessObserver constructor) looks like:

  if (!command_line.HasSwitch(switches::kSingleProcess)) {
    // We are going to fork to engage the sandbox and we have not loaded
    // any security modules so it is safe to disable the fork check in NSS.
    crypto::DisableNSSForkCheck();
    crypto::ForceNSSNoDBInit();
    crypto::EnsureNSSInit();
  }

[1] http://code.google.com/p/chromium/wiki/LinuxSUIDSandbox

Message #104 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Mike Hommey <mh@glandium.org>

Cc: libnss3-1d@packages.debian.org, Sebastian Reichel <sre@debian.org>, 647992@bugs.debian.org

Subject: Re: chromium 14 broken with libnss3-1d from sid

Date: Tue, 15 Nov 2011 20:19:20 -0600

Jonathan Nieder wrote:

> All I know is that changing the source to say
>
> 	if (nodb_init) {
> 	  std::cerr << "about to call NSS_NoDB_Init(NULL)\n";
> 	  status = NSS_NoDB_Init(NULL);
> 	  std::cerr << "finished NSS_NoDB_Init(NULL)\n";
>
> causes the "about to call" line to be printed, but the "finished" line
> not to.

Weird.  It ends in here (mozilla/security/nss/lib/freebl/drbg.c):

| static PRStatus rng_init(void)
| {
|     PRUint8 bytes[PRNG_SEEDLEN*2]; /* entropy + nonce */
|     unsigned int numBytes;
|     fprintf(stderr, "not printed\n");		<--- not reached
[...]
| SECStatus
| RNG_RNGInit(void)
| {
|     /* Allow only one call to initialize the context */
|     fprintf(stderr, "about to call rng_init()\n");	<--- reached
|     PR_CallOnce(&coRNGInit, rng_init);
|     fprintf(stderr, "not printed\n");		<--- not reached

Call chain:

 ... -> NSC_Initialize() -> nsc_CommonInitialize() ->
  loader.c::RNGInit() -> drbg.c::RNG_RNGInit()

Message #109 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: Mike Hommey <mh@glandium.org>, libnss3-1d@packages.debian.org, Sebastian Reichel <sre@debian.org>, 647992@bugs.debian.org

Subject: Re: chromium 14 broken with libnss3-1d from sid

Date: Sat, 19 Nov 2011 13:46:35 +0100

[Message part 1 (text/plain, inline)]

OoO En  ce milieu  de nuit  étoilée du mercredi  16 novembre  2011, vers
03:19, Jonathan Nieder <jrnieder@gmail.com> disait :

>> All I know is that changing the source to say
>> 
>> if (nodb_init) {
>> std::cerr << "about to call NSS_NoDB_Init(NULL)\n";
>> status = NSS_NoDB_Init(NULL);
>> std::cerr << "finished NSS_NoDB_Init(NULL)\n";
>> 
>> causes the "about to call" line to be printed, but the "finished" line
>> not to.

> Weird.  It ends in here (mozilla/security/nss/lib/freebl/drbg.c):

> | static PRStatus rng_init(void)
> | {
> |     PRUint8 bytes[PRNG_SEEDLEN*2]; /* entropy + nonce */
> |     unsigned int numBytes;
> |     fprintf(stderr, "not printed\n");		<--- not reached
> [...]
> | SECStatus
> | RNG_RNGInit(void)
> | {
> |     /* Allow only one call to initialize the context */
> |     fprintf(stderr, "about to call rng_init()\n");	<--- reached
> |     PR_CallOnce(&coRNGInit, rng_init);
> |     fprintf(stderr, "not printed\n");		<--- not reached

> Call chain:

>  ... -> NSC_Initialize() -> nsc_CommonInitialize() ->
>   loader.c::RNGInit() -> drbg.c::RNG_RNGInit()

I have  tried to help too but  I don't have enough  resources to compile
Chromium.  I was  thinking modifying  setuid  helper to  not chroot  nor
change its namespace. If the bug is still present in this configuration,
this would allow to get an appropriate core dump.

In sandbox.c,  I would suppress  chdir(), chroot() and chdir()  calls in
SpawnChrootHelper().  I  would  also  replace  MoveToNewNamespaces()  by
"return true;". Running with no limit  for core dumps would allow to get
a core file. Maybe this will give additional hints.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

#define BB_STAT2_TMP_INTR    0x10    /* My Penguins are burning. 
Are you able to smell it? */
        2.2.16 /usr/src/linux/include/asm-sparc/obio.h

[Message part 2 (application/pgp-signature, inline)]

Message #114 received at 647992@bugs.debian.org (full text, mbox, reply):

From: "Fabien C." <3uruyp1k7asc4ba@jetable.org>

To: Vincent Bernat <bernat@debian.org>

Cc: 647992@bugs.debian.org

Subject: Re: chromium 14 broken with libnss3-1d from sid

Date: Sat, 19 Nov 2011 18:44:39 +0100

> In sandbox.c,  I would suppress  chdir(), chroot() and chdir()  calls in
> SpawnChrootHelper().  I  would  also  replace  MoveToNewNamespaces()  by
> "return true;". Running with no limit  for core dumps would allow to get
> a core file. Maybe this will give additional hints.

I may be wrong here, but couldn't you use the --no-sandbox option instead? 

Message #119 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: "Fabien C." <3uruyp1k7asc4ba@jetable.org>

Cc: 647992@bugs.debian.org, Vincent Bernat <bernat@debian.org>

Subject: Re: chromium 14 broken with libnss3-1d from sid

Date: Sat, 19 Nov 2011 12:25:09 -0600

Fabien C. wrote:

> I may be wrong here, but couldn't you use the --no-sandbox option instead? 

Unfortunately "chromium --no-sandbox" doesn't exhibit the problem.

Vincent (or anyone else), if you send debugging patches, I can, with
time, test them.  Though this is not a particularly beefy laptop.
Linking chromium takes a while because the working set of the linker
seems not to fit in RAM (2 GiB of RAM with 256 MiB of that stolen by
the video card).

Message #126 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: 647992@bugs.debian.org

Cc: Yves-Alexis Perez <corsac@debian.org>, Sebastian Reichel <sre@debian.org>

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Sun, 20 Nov 2011 23:36:56 -0600

Mattia Monga wrote:

> Chromium starts with a Aw, Snap! page and it is stuck on that. 

Still not clear what the underlying cause is (maybe libnspr is not
available in the sandboxed renderers to resolve weak references or
something like that), but here's a patch to get back to the version 14
behavior, of NSS modules not causing trouble because they are not
loaded at all.

Even with this patch, I can't reproduce the problem described at
http://bugs.debian.org/642219 (i.e., https://mail.google.com loads
fine, even with --user-data-dir=/tmp/nonexistent).

Maybe something along these lines can work as a temporary way to help
people use chromium with sandboxing until we figure the actual cause
out.

Yuck.  I'd go for something more explicit like --without-nss if it
existed.
---
 debian/patches/nss-workaround.patch |   49 +++++++++++++++++++++++++++++++++++
 debian/patches/series               |    1 +
 2 files changed, 50 insertions(+), 0 deletions(-)
 create mode 100644 debian/patches/nss-workaround.patch

diff --git a/debian/patches/nss-workaround.patch b/debian/patches/nss-workaround.patch
new file mode 100644
index 00000000..00c06745
--- /dev/null
+++ b/debian/patches/nss-workaround.patch
@@ -0,0 +1,47 @@
+Subject: Revert "Merge 104421 - Fix library paths for preloading NSS on Ubuntu 11.10."
+
+This backs out the change introduced by r104798, which allowed NSS to
+actually be initialized, where "initialized" means "trip a sandboxing
+bug and take down the renderer".
+
+Works around: http://bugs.debian.org/647992
+
+--- 874/src/crypto/nss_util.cc	2011/10/10 22:14:15	104798
++++ 874/src/crypto/nss_util.cc	2011/10/10 22:11:59	104797
+@@ -29,7 +29,6 @@
+ #include "base/native_library.h"
+ #include "base/stringprintf.h"
+ #include "base/threading/thread_restrictions.h"
+-#include "build/build_config.h"
+ #include "crypto/scoped_nss_types.h"
+ 
+ // USE_NSS means we use NSS for everything crypto-related.  If USE_NSS is not
+@@ -604,18 +603,9 @@
+   // Use relative path to Search PATH for the library files.
+   paths.push_back(FilePath());
+ 
++  // For Debian derivaties NSS libraries are located here.
+-  // For Debian derivatives NSS libraries are located here.
+   paths.push_back(FilePath("/usr/lib/nss"));
+ 
+-  // Ubuntu 11.10 (Oneiric) places the libraries here.
+-#if defined(ARCH_CPU_X86_64)
+-  paths.push_back(FilePath("/usr/lib/x86_64-linux-gnu/nss"));
+-#elif defined(ARCH_CPU_X86)
+-  paths.push_back(FilePath("/usr/lib/i386-linux-gnu/nss"));
+-#elif defined(ARCH_CPU_ARMEL)
+-  paths.push_back(FilePath("/usr/lib/arm-linux-gnueabi/nss"));
+-#endif
+-
+   // A list of library files to load.
+   std::vector<std::string> libs;
+   libs.push_back("libsoftokn3.so");
+@@ -638,7 +628,7 @@
+   if (loaded == libs.size()) {
+     VLOG(3) << "NSS libraries loaded.";
+   } else {
++    LOG(WARNING) << "Failed to load NSS libraries.";
+-    LOG(ERROR) << "Failed to load NSS libraries.";
+   }
+ #endif
+ }
diff --git a/debian/patches/series b/debian/patches/series
index ad74c539..0f1cdaae 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -18,3 +18,4 @@ webkit-version.patch
 cups1.5.patch
 #system_v8.patch
 #protobuf.patch
+nss-workaround.patch
-- 
1.7.8.rc3

Message #131 received at 647992@bugs.debian.org (full text, mbox, reply):

From: "brian m. carlson" <sandals@crustytoothpaste.net>

To: 647992@bugs.debian.org

Subject: Progress?

Date: Sun, 27 Nov 2011 23:12:44 +0000

[Message part 1 (text/plain, inline)]

This bug log hasn't been updated in a week.  Is there any reason the
proposed patch isn't acceptable?  chromium is broken in its default
configuration and the current workaround has significant security
implications.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[signature.asc (application/pgp-signature, inline)]

Message #136 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: "brian m. carlson" <sandals@crustytoothpaste.net>

Cc: 647992@bugs.debian.org

Subject: Re: Bug#647992: Progress?

Date: Tue, 29 Nov 2011 06:10:04 -0600

Hi,

brian m. carlson wrote:

> This bug log hasn't been updated in a week.  Is there any reason

My guess is <http://bugs.debian.org/583826> is the reason.

I've been locally using the patch from this bug log (and it works as
advertised), but I'm not proud of it.  Next time there are some spare
moments, I'd like to try disabling sandboxing features as Vincent
suggested one at a time, to find out which one libnss doesn't
tolerate.

Thanks for your interest (and thanks for your many pleasant and well
written bug reports),
Jonathan

Message #143 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Nix <nix@esperi.org.uk>

To: 647992@bugs.debian.org

Subject: Possible cause (unlikely)

Date: Mon, 05 Dec 2011 12:41:58 +0000

Briefly:

Because Debian is using kernel 3.1.x and has CONFIG_SECCOMP turned on,
all attempts to call time() with the seccomp sandbox active and using a
glibc old enough that it uses the vsyscall page for such calls will 'Aw,
snap!' the renderer:

<http://code.google.com/p/chromium/issues/detail?id=104084>
<http://code.google.com/p/seccompsandbox/issues/detail?id=17>

This is fixed, but very recently... but this is likely moot since Debian
doesn't turn on the seccomp sandbox. When you do, take note...

Message #150 received at 647992-close@bugs.debian.org (full text, mbox, reply):

From: Giuseppe Iuculano <iuculano@debian.org>

To: 647992-close@bugs.debian.org

Subject: Bug#647992: fixed in chromium-browser 15.0.874.121~r109964-1

Date: Wed, 07 Dec 2011 10:52:20 +0000

Source: chromium-browser
Source-Version: 15.0.874.121~r109964-1

We believe that the bug you reported is fixed in the latest version of
chromium-browser, which is due to be installed in the Debian FTP archive:

chromium-browser-dbg_15.0.874.121~r109964-1_all.deb
  to main/c/chromium-browser/chromium-browser-dbg_15.0.874.121~r109964-1_all.deb
chromium-browser-inspector_15.0.874.121~r109964-1_all.deb
  to main/c/chromium-browser/chromium-browser-inspector_15.0.874.121~r109964-1_all.deb
chromium-browser-l10n_15.0.874.121~r109964-1_all.deb
  to main/c/chromium-browser/chromium-browser-l10n_15.0.874.121~r109964-1_all.deb
chromium-browser_15.0.874.121~r109964-1.debian.tar.gz
  to main/c/chromium-browser/chromium-browser_15.0.874.121~r109964-1.debian.tar.gz
chromium-browser_15.0.874.121~r109964-1.dsc
  to main/c/chromium-browser/chromium-browser_15.0.874.121~r109964-1.dsc
chromium-browser_15.0.874.121~r109964-1_all.deb
  to main/c/chromium-browser/chromium-browser_15.0.874.121~r109964-1_all.deb
chromium-browser_15.0.874.121~r109964.orig.tar.bz2
  to main/c/chromium-browser/chromium-browser_15.0.874.121~r109964.orig.tar.bz2
chromium-dbg_15.0.874.121~r109964-1_amd64.deb
  to main/c/chromium-browser/chromium-dbg_15.0.874.121~r109964-1_amd64.deb
chromium-inspector_15.0.874.121~r109964-1_all.deb
  to main/c/chromium-browser/chromium-inspector_15.0.874.121~r109964-1_all.deb
chromium-l10n_15.0.874.121~r109964-1_all.deb
  to main/c/chromium-browser/chromium-l10n_15.0.874.121~r109964-1_all.deb
chromium_15.0.874.121~r109964-1_amd64.deb
  to main/c/chromium-browser/chromium_15.0.874.121~r109964-1_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 647992@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Giuseppe Iuculano <iuculano@debian.org> (supplier of updated chromium-browser package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 07 Dec 2011 09:12:54 +0100
Source: chromium-browser
Binary: chromium-browser chromium-browser-dbg chromium-browser-l10n chromium-browser-inspector chromium chromium-dbg chromium-l10n chromium-inspector
Architecture: source all amd64
Version: 15.0.874.121~r109964-1
Distribution: unstable
Urgency: high
Maintainer: Debian Chromium Maintainers <pkg-chromium-maint@lists.alioth.debian.org>
Changed-By: Giuseppe Iuculano <iuculano@debian.org>
Description: 
 chromium   - Google's open source chromium web browser
 chromium-browser - Chromium browser - transitional dummy package
 chromium-browser-dbg - chromium-browser debug symbols transitional dummy package
 chromium-browser-inspector - page inspector for the chromium-browser - transitional dummy pack
 chromium-browser-l10n - chromium-browser language packages - transitional dummy package
 chromium-dbg - Debugging symbols for the chromium web browser
 chromium-inspector - page inspector for the chromium browser
 chromium-l10n - chromium-browser language packages
Closes: 644526 647992
Changes: 
 chromium-browser (15.0.874.121~r109964-1) unstable; urgency=high
 .
   [ Jonathan Nieder ]
   * [f67eee0] chromium-inspector: Recommend chromium (>= 10) to avoid pulling in chromium-bsu
   * [4de64d5] Use /etc/debian_version, not `lsb_release -sr`, to populate BUILD_DIST
   * [7dba3cb] Permit '/' in Debian release names (Closes: #644526)
   * [aa996fe] Unbreak get-orig-source in non-C locales by using "svn log --xml" instead of "svn info"
 .
   [ Giuseppe Iuculano ]
   * [dc3b8be] Revert "Merge 104421 - Fix library paths for preloading NSS on Ubuntu 11.10."
     Thanks to Jonathan Nieder (Closes: #647992)
   * [d729967] Use system v8
   * New stable release:
     - High CVE-2011-3892: Double free in Theora decoder.
       Credit to Aki Helin of OUSPG.
     - Medium CVE-2011-3893: Out of bounds reads in MKV and
       Vorbis media handlers. Credit to Aki Helin of OUSPG.
     - High CVE-2011-3894: Memory corruption regression in VP8 decoding.
       Credit to Andrew Scherkus of the Chromium development community.
     - High CVE-2011-3895: Heap overflow in Vorbis decoder. Credit
       to Aki Helin of OUSPG.
     - High CVE-2011-3896: Buffer overflow in shader variable mapping.
       Credit to Ken “strcpy” Russell of the Chromium development community.
     - High CVE-2011-3897: Use-after-free in editing. Credit to pa_kt
       reported through ZDI (ZDI-CAN-1416).
     - Low CVE-2011-3898: Failure to ask for permission to run applets in
       JRE7. Credit to Google Chrome Security Team (Chris Evans).
     - High CVE-2011-3900: Out-of-bounds write in v8. Credit to Christian
       Holler.
Checksums-Sha1: 
 f87b9e027557dde74c3e5e1a122642fbd9336264 2912 chromium-browser_15.0.874.121~r109964-1.dsc
 c6da3a9c98a8b8191b74cb6cc3c3e48cee85c617 260521506 chromium-browser_15.0.874.121~r109964.orig.tar.bz2
 04a29f9a8ecbaa7c3b6a6cb25f3f092e31913aed 239925 chromium-browser_15.0.874.121~r109964-1.debian.tar.gz
 643ac9687bdf21d163c9841badd336baeff7b72b 176804 chromium-browser_15.0.874.121~r109964-1_all.deb
 6f2c8e423f3d66a5cc5d54ec67612f12ea34d2cf 175900 chromium-browser-dbg_15.0.874.121~r109964-1_all.deb
 940b41816c697deeec03b1c3517688e01d54843f 176042 chromium-browser-l10n_15.0.874.121~r109964-1_all.deb
 928e51175146d7c1bfc11d978ab7d04f8d431d6d 175914 chromium-browser-inspector_15.0.874.121~r109964-1_all.deb
 cee615a00680c19b53d6a3b8730c84edf24ce1c8 2918902 chromium-l10n_15.0.874.121~r109964-1_all.deb
 871064f66c013c9f52c609088326420b8b3fb9b6 782844 chromium-inspector_15.0.874.121~r109964-1_all.deb
 5ae6ab63e35f82e9bcac241fe12c11e90f25d774 26430170 chromium_15.0.874.121~r109964-1_amd64.deb
 6223386956e8a5dd3a44a1c782566bc7d3c0fae6 396777366 chromium-dbg_15.0.874.121~r109964-1_amd64.deb
Checksums-Sha256: 
 3c2aae4f4b5189d3050931edccd67a8e49b03f22d700424138721c429893b09d 2912 chromium-browser_15.0.874.121~r109964-1.dsc
 8b6f93bdb80c64c19624855b03f4d1a2576d5938d9de9802840e746c85ad9b48 260521506 chromium-browser_15.0.874.121~r109964.orig.tar.bz2
 83c5305ab461776d4e290010fbbbff130d0f7886ab6b72ae0b8c607c225fd0a4 239925 chromium-browser_15.0.874.121~r109964-1.debian.tar.gz
 1a598f2b4b882141dad8a6caa5008bd7bf54fa725482cfe60ed23713f37c4aae 176804 chromium-browser_15.0.874.121~r109964-1_all.deb
 350c83b7394932564885053f8d371fc25f69b685c0094ec1e5fb51399b975086 175900 chromium-browser-dbg_15.0.874.121~r109964-1_all.deb
 199cdd77981dd7eddedcf537a90932429dab42f6d273d86840d09eb14af3ca24 176042 chromium-browser-l10n_15.0.874.121~r109964-1_all.deb
 1882c8f089fb6f34a98cc90fcbb1e8ac35eec9e28dce5b09494d9c09a179654a 175914 chromium-browser-inspector_15.0.874.121~r109964-1_all.deb
 7004ee344f8b4081e28ed9b8960470b4e7a2444c18aec2fc4b5aaab54b9b47c4 2918902 chromium-l10n_15.0.874.121~r109964-1_all.deb
 d03bb4190a3e10b01daca0c13756f31f17fe4b7c5ea2eb0a153033f43f7b5a39 782844 chromium-inspector_15.0.874.121~r109964-1_all.deb
 f0be1fea6e5f1175f4e3a538b539c0466d537b6679d52c4b290dfa56ed6229bf 26430170 chromium_15.0.874.121~r109964-1_amd64.deb
 f7745d396ce1e08d248e850d8db259544583cfbc41e7d0f245fe5677c4db2a38 396777366 chromium-dbg_15.0.874.121~r109964-1_amd64.deb
Files: 
 2bab3b2565efddde01fbc6a8ddfede1e 2912 web optional chromium-browser_15.0.874.121~r109964-1.dsc
 d78a244f5c806fc5440e14f397e7ee49 260521506 web optional chromium-browser_15.0.874.121~r109964.orig.tar.bz2
 935df26fd8179b8815853d791806faa6 239925 web optional chromium-browser_15.0.874.121~r109964-1.debian.tar.gz
 60451d092dd49f9baef9bc52e12961d1 176804 oldlibs optional chromium-browser_15.0.874.121~r109964-1_all.deb
 aa3851fc1a0c691583b98e72846ddeec 175900 oldlibs extra chromium-browser-dbg_15.0.874.121~r109964-1_all.deb
 b38160dac746d5150da8c6c0788314aa 176042 oldlibs optional chromium-browser-l10n_15.0.874.121~r109964-1_all.deb
 3461973e468cf7592f815622dc8e09a8 175914 oldlibs optional chromium-browser-inspector_15.0.874.121~r109964-1_all.deb
 7a2b16e886d845b1f9c40fb133e1d145 2918902 web optional chromium-l10n_15.0.874.121~r109964-1_all.deb
 60fe505e3ed247911ce62d39efef4814 782844 web optional chromium-inspector_15.0.874.121~r109964-1_all.deb
 6d24a2caf227cce310f174495025d95e 26430170 web optional chromium_15.0.874.121~r109964-1_amd64.deb
 de405f2adf6a5b8d46dda68429567e64 396777366 debug extra chromium-dbg_15.0.874.121~r109964-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7fPzkACgkQNxpp46476aruVgCdHvd3Gq5jLnWNQ4RHTpeOH1p4
M1UAn3LHs56ykl2Haipfz6GEStbXhG89
=+lQz
-----END PGP SIGNATURE-----

Message #210 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Frederik Schwarzer <schwarzerf@gmail.com>

To: 647992@bugs.debian.org

Subject: Thanks!

Date: Fri, 9 Dec 2011 13:53:11 +0100

Thanks a lot for working this out. :)

Message #215 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jeffry Smith <jsmith@alum.mit.edu>

To: 647992@bugs.debian.org

Subject: Need to re-open

Date: Mon, 12 Dec 2011 00:17:51 -0500

Still get "Aw Snap!" when trying to start Chromium.

Chromium:  aptitude versions chromium
p   14.0.835.202~r103287-1                        testing                   500
i   15.0.874.121~r109964-1                        unstable                  500

Libnss3-1d: aptitude versions libnss3-1d
i A 3.13.1.with.ckbi.1.88-1                       testing,unstable          500

Message #220 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: jsmith@alum.mit.edu

Cc: 647992@bugs.debian.org

Subject: Re: Need to re-open

Date: Mon, 12 Dec 2011 12:29:36 -0600

Jeffry Smith wrote:

> Still get "Aw Snap!" when trying to start Chromium.

Works for me.  Please file a new bug.

Thanks,
Jonathan

Message #225 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Daniel Baumann <daniel.baumann@progress-technologies.net>

To: 647992@bugs.debian.org

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Mon, 02 Jan 2012 10:41:46 +0100

reopen 647992
found 16.0.912.63~r113337-1
severity 647992 normal
thanks

Hi,

the issue still persists when backporting for squeeze. builds (any
version 14 till 16 is affected by it atm) can be found at:


http://archive-master.progress-linux.org/packages/backports/progress-artax-backports/chromium-browser/

git tree is at:

  http://vcs.progress-linux.org/?p=packages/chromium-browser.git

the builds are done against plain squeeze plus backports of libv8, nss,
nspr, and cairo (which is the same you would get on backports.d.o i
presume).

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #234 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: daniel.baumann@progress-technologies.net

Cc: 647992@bugs.debian.org

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Mon, 2 Jan 2012 03:51:50 -0600

unmerge 647992
clone 647992 -1
merge -1 647994
submitter 647992 Daniel Baumann <daniel.baumann@progress-technologies.net>
tags 647992 = squeeze
block 647992 by 651912
retitle 647992 [squeeze-backports] chromium: unrecoverable Aw, Snap! on start up
quit

Daniel Baumann wrote:

> the issue still persists when backporting for squeeze.

Ok, we can keep a bug open for that.  I'll close the old bug with a
separate message.

Message #251 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Daniel Baumann <daniel.baumann@progress-technologies.net>

Cc: 647992@bugs.debian.org

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Mon, 2 Jan 2012 14:37:09 -0600

severity 647992 wishlist
tags 647992 + moreinfo
quit

Hi again,

Daniel Baumann wrote:

> the issue still persists when backporting for squeeze.
[...]
> the builds are done against plain squeeze plus backports of libv8, nss,
> nspr, and cairo (which is the same you would get on backports.d.o i
> presume).

chromium isn't available from backports.d.o.

Do you think it would make sense to add it there, and if so, would you
be willing to work on it?  What change, if any, should be made to the
standard chromium package to support that?

Sorry for the trouble and hope that helps,
Jonathan

Message #260 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Daniel Baumann <daniel.baumann@progress-technologies.net>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Mon, 02 Jan 2012 21:51:32 +0100

On 01/02/2012 09:37 PM, Jonathan Nieder wrote:
> Do you think it would make sense to add it there

imho yes.

> would you be willing to work on it

to the extend as its relevent for the derivative, other than that, no.

however, my git tree is public, anyone can always pick from it in case
there would ever be anything interesting in the future.

> What change, if any, should be made to the
> standard chromium package to support that?

like other packages do, chromium-browser should build-depend on
lsb-release and default automatically to certain settings depending on
if it's build on sid or squeeze.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #267 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <michael.s.gilbert@gmail.com>

To: daniel.baumann@progress-technologies.net, 647992@bugs.debian.org

Subject: Re: Bug#647992: chromium: unrecoverable Aw, Snap! on start up

Date: Tue, 3 Jan 2012 18:44:51 -0500

>> What change, if any, should be made to the
>> standard chromium package to support that?
>
> like other packages do, chromium-browser should build-depend on
> lsb-release and default automatically to certain settings depending on
> if it's build on sid or squeeze.

Which settings in particular do you know of that make the chromium
backport work?

Best wishes,
Mike

Message #272 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Daniel Baumann <daniel.baumann@progress-technologies.net>

To: Michael Gilbert <michael.s.gilbert@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: Bug#647992: chromium: unrecoverable Aw, Snap! on start up

Date: Wed, 04 Jan 2012 10:29:34 +0100

On 01/04/2012 12:44 AM, Michael Gilbert wrote:
> Which settings in particular do you know of that make the chromium
> backport work?

haven't you looked at the git repository[0]? e.g. 'git diff
debian-wheezy..progress-artax-backports' gives all the changes.

citing from changelog:

---snip---
chromium-browser (16.0.912.63~r113337-1~artax1) artax; urgency=low

  * Uploading to artax, remaining changes:
    - Updating maintainer and uploaders fields.
    - Updating vcs fields.
    - Adding bugs field.
    - Always building for debian-squeeze rather than autodetecting
      distribution, vendor and release number with lsb_release.
    - Reverting use of binutils-gold to fix FTBFS.
    - Reverting changes for cups (>= 1.5).
    - Reverting changes to use system ffmpeg.
    - Reverting changes for multiarch.
    - Updating chromium install file for upstreams ffmpegsumo_nolink
removal.

 -- Daniel Baumann <daniel.baumann@progress-linux.org>  Mon, 02 Jan 2012
07:17:39 +0100
---snap---

[0] http://vcs.progress-linux.org/?p=packages/chromium-browser.git

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #277 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <michael.s.gilbert@gmail.com>

To: 647992@bugs.debian.org

Subject: Re: Bug#647992: chromium: unrecoverable Aw, Snap! on start up

Date: Wed, 4 Jan 2012 19:35:36 -0500

On Wed, Jan 4, 2012 at 4:29 AM, Daniel Baumann wrote:
> On 01/04/2012 12:44 AM, Michael Gilbert wrote:
>> Which settings in particular do you know of that make the chromium
>> backport work?
>
> haven't you looked at the git repository[0]? e.g. 'git diff
> debian-wheezy..progress-artax-backports' gives all the changes.

Yes, I looked at a diff, but it wasn't immediately obvious which
change would actually solve the problem.  They're all rather mundane
changes each individually seemingly unlikely to fix these crashes.
Anyway, I'll take your word for it, and track down which of your
changes really fix the problem.

Best wishes,
Mike

Message #282 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Daniel Baumann <daniel.baumann@progress-technologies.net>

To: Michael Gilbert <michael.s.gilbert@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: Bug#647992: chromium: unrecoverable Aw, Snap! on start up

Date: Fri, 06 Jan 2012 17:56:06 +0100

Michael Gilbert <michael.s.gilbert@gmail.com> wrote:
> Yes, I looked at a diff, but it wasn't immediately obvious which
> change would actually solve the problem.

i think we have a misunderstanding here, i never claimed to have a 
solution for the fix, rather, i reopened this bug *because* it still 
doesn't work. sorry for no better news, i'm happy to test whatever you 
want me to test though.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #287 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Daniel Baumann <daniel.baumann@progress-technologies.net>

To: 647992@bugs.debian.org

Subject: Re: [squeeze-backports] chromium: unrecoverable Aw, Snap! on start up

Date: Thu, 09 Feb 2012 23:59:34 +0100

just to let you know, i've given up on chromium and stick with iceweasel
for the time being. so, feel free to close the bug if you like.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #292 received at 647992@bugs.debian.org (full text, mbox, reply):

From: "Mark T. B. Carroll" <mtbc@ixod.org>

To: 647992@bugs.debian.org

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Sun, 12 Feb 2012 18:02:35 -0500

I found this bug because of experiencing the same failure. I use
squeeze but installed with apt-get install -t testing chromium-browser

The --single-process option corrects the problem for me.

Mark

Message #297 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Ariel <asdebian@dsgml.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: Daniel Baumann <daniel.baumann@progress-technologies.net>, 647992@bugs.debian.org

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Sun, 13 May 2012 21:01:02 -0400 (EDT)

On Mon, 2 Jan 2012, Jonathan Nieder wrote:

> chromium isn't available from backports.d.o.
>
> Do you think it would make sense to add it there, and if so, would you
> be willing to work on it?  What change, if any, should be made to the
> standard chromium package to support that?

The main thing I had an issue with when backporting it for myself was 
the versioned dependency on libcups2-dev >= 1.5.0.

Installing that from testing pulled a huge number of other packages along 
with it.

Everything else was available from backports or was just a single package 
(I believe gyp, libwebp-dev and libv8 were the only ones I needed from 
testing).

(I had the same NSS issues as everyone else, but somehow 3.13.4-1 broke 
nss for chromium and now chromium works - although for me using 
--single-process would not have been a problem.)

	-Ariel

Message #302 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Ariel <asdebian@dsgml.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: Daniel Baumann <daniel.baumann@progress-technologies.net>, 647992@bugs.debian.org

Subject: Re: chromium: unrecoverable Aw, Snap! on start up

Date: Sun, 13 May 2012 22:03:56 -0400 (EDT)

On Sun, 13 May 2012, Ariel wrote:

> The main thing I had an issue with when backporting it for myself was the 
> versioned dependency on libcups2-dev >= 1.5.0.
>
> Installing that from testing pulled a huge number of other packages along 
> with it.
>
> Everything else was available from backports or was just a single package (I 
> believe gyp, libwebp-dev and libv8 were the only ones I needed from testing).

Actually, never mind. libwebp-dev needs multiarch-support, which is only 
available in the same toolchain that comes in via libcups2-dev >= 1.5.0

Maybe if someone backported a non multiarch-support libwebp-dev, but 
simply compiling it on squeeze was not enough. I guess the paths, etc are 
different. I guess I'll have to run a mixed system if I want chromium.

	-Ariel

Message #307 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Oleg Kostyuk <cub.uanic@gmail.com>

To: Debian Bug Tracking System <647992@bugs.debian.org>

Subject: Re: unrecoverable Aw, Snap! on start up

Date: Thu, 07 Jun 2012 03:06:30 +0300

Package: chromium
Version: 18.0.1025.151~r130497-1
Severity: normal

Exactly same problem here.
My system is Squeeze with Chomium/testing.
Option "--single-process" does solve this problem, but annoying.

OTOH, on other system, which is completely "testing" - this problems
doesn't appear at all.

Will be happy to provide additional information and to help solve this.
Thanks!



-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (810, 'stable-updates'), (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages chromium depends on:
ii  chromium-inspect 18.0.1025.151~r130497-1 page inspector for the chromium br
ii  gconf-service    3.2.5-1                 GNOME configuration database syste
ii  libasound2       1.0.23-2.1              shared library for ALSA applicatio
ii  libavcodec53     6:0.8.2-2               Libav codec library
ii  libavformat53    6:0.8.2-2               Libav file format library
ii  libavutil51      6:0.8.2-2               Libav utility library
ii  libbz2-1.0       1.0.5-6+squeeze1        high-quality block-sorting file co
ii  libc6            2.13-32                 Embedded GNU C Library: Shared lib
ii  libcairo2        1.8.10-6                The Cairo 2D vector graphics libra
ii  libcups2         1.4.4-7+squeeze1        Common UNIX Printing System(tm) - 
ii  libdbus-1-3      1.2.24-4+squeeze1       simple interprocess messaging syst
ii  libevent-2.0-5   2.0.19-stable-2         Asynchronous event notification li
ii  libexpat1        2.0.1-7                 XML parsing C library - runtime li
ii  libflac8         1.2.1-2+b1              Free Lossless Audio Codec - runtim
ii  libfontconfig1   2.8.0-2.1               generic font configuration library
ii  libfreetype6     2.4.2-2.1+squeeze4      FreeType 2 font engine, shared lib
ii  libgcc1          1:4.7.0-8               GCC support library
ii  libgconf-2-4     3.2.5-1                 GNOME configuration database syste
ii  libgcrypt11      1.4.5-2                 LGPL Crypto library - runtime libr
ii  libgdk-pixbuf2.0 2.26.1-1                GDK Pixbuf library
ii  libglib2.0-0     2.32.3-1                GLib library of C routines
ii  libgtk2.0-0      2.24.10-1               GTK+ graphical user interface libr
ii  libjpeg8         8d-1                    Independent JPEG Group's JPEG runt
ii  libnspr4-0d      4.8.6-1                 NetScape Portable Runtime Library
ii  libnss3-1d       3.12.8-1+squeeze4       Network Security Service libraries
ii  libpango1.0-0    1.28.3-1+squeeze2       Layout and rendering of internatio
ii  libpng12-0       1.2.44-1+squeeze4       PNG library - runtime
ii  libpulse0        2.0-3                   PulseAudio client libraries
ii  libspeex1        1.2~rc1-1               The Speex codec runtime library
ii  libstdc++6       4.7.0-8                 GNU Standard C++ Library v3
ii  libudev0         164-3                   libudev shared library
ii  libwebp2         0.1.3-3                 Lossy compression of digital photo
ii  libx11-6         2:1.3.3-4               X11 client-side library
ii  libxext6         2:1.1.2-1               X11 miscellaneous extension librar
ii  libxfixes3       1:4.0.5-1               X11 miscellaneous 'fixes' extensio
ii  libxml2          2.7.8.dfsg-2+squeeze4   GNOME XML library
ii  libxrender1      1:0.9.6-1               X Rendering Extension client libra
ii  libxslt1.1       1.1.26-6                XSLT 1.0 processing library - runt
ii  libxss1          1:1.2.0-2               X11 Screen Saver extension library
ii  xdg-utils        1.0.2+cvs20100307-2     desktop integration utilities from
ii  zlib1g           1:1.2.3.4.dfsg-3        compression library - runtime

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-l10n                 <none>     (no description available)

-- no debconf information

Message #312 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Oleg Kostyuk <cub.uanic@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: unrecoverable Aw, Snap! on start up

Date: Wed, 6 Jun 2012 19:30:26 -0500

tags 647992 - squeeze
forcemerge 651912 647992
quit

Hi Oleg,

Oleg Kostyuk wrote:

> Exactly same problem here.
> My system is Squeeze with Chomium/testing.
> Option "--single-process" does solve this problem, but annoying.

This should be fixed in nspr 2:4.9-2.  If that doesn't help, please
do let us know so we can revisit it.

Hope that helps,
Jonathan

Message #323 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Oleg Kostyuk <cub.uanic@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: unrecoverable Aw, Snap! on start up

Date: Thu, 7 Jun 2012 16:03:30 +0300

Hi,

Seems I did just typo, and instead of installing libnspr4-0d/testng, I
installed libnss3-1d/testing. Surprisingly, but this solved my
problem. And I realized that I upgraded other package only when I
started writing this reply.

So, now I have installed libnss3-1d/testing and libnspr4-0d/stable,
and problem doesn't appear:

# dpkg -l | egrep libnspr\|libnss\|chromium
ii  chromium                             18.0.1025.151~r130497-1
    Google's open source chromium web browser
ii  chromium-inspector                   18.0.1025.151~r130497-1
    page inspector for the chromium browser
ii  libnspr4-0d                          4.8.6-1
    NetScape Portable Runtime Library
ii  libnss3                              2:3.13.4-3
    Network Security Service libraries
ii  libnss3-1d                           2:3.13.4-3
    Network Security Service libraries - transitional package

Would you like me to try to install libnss3-1d/stable and libnspr4-0d/testing?

Thanks for help!


2012/6/7 Jonathan Nieder <jrnieder@gmail.com>:
> tags 647992 - squeeze
> forcemerge 651912 647992
> quit
>
> Hi Oleg,
>
> Oleg Kostyuk wrote:
>
>> Exactly same problem here.
>> My system is Squeeze with Chomium/testing.
>> Option "--single-process" does solve this problem, but annoying.
>
> This should be fixed in nspr 2:4.9-2.  If that doesn't help, please
> do let us know so we can revisit it.
>
> Hope that helps,
> Jonathan



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

Message #330 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Oleg Kostyuk <cub.uanic@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: unrecoverable Aw, Snap! on start up

Date: Thu, 7 Jun 2012 15:17:50 -0500

Oleg Kostyuk wrote:

> Seems I did just typo, and instead of installing libnspr4-0d/testng, I
> installed libnss3-1d/testing. Surprisingly, but this solved my
> problem.

Gah.

[...]
> Would you like me to try to install libnss3-1d/stable and libnspr4-0d/testing?

Sure, yes that would be interesting.

Thanks,
Jonathan

Message #335 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Oleg Kostyuk <cub.uanic@gmail.com>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: unrecoverable Aw, Snap! on start up

Date: Fri, 8 Jun 2012 00:25:44 +0300

Hm.

Seems this way also solve my problem.
Now I have:

# dpkg -l | egrep libnspr\|libnss\|chromium
ii  chromium                             18.0.1025.151~r130497-1
    Google's open source chromium web browser
ii  chromium-inspector                   18.0.1025.151~r130497-1
    page inspector for the chromium browser
ii  libnspr4                             2:4.9-3
    NetScape Portable Runtime Library
ii  libnspr4-0d                          2:4.9-3
    NetScape Portable Runtime Library - transitional package
ii  libnss3-1d                           3.12.8-1+squeeze4
    Network Security Service libraries

And everything works fine.

But what was the root of the problem - libnss or libnspr ?..


2012/6/7 Jonathan Nieder <jrnieder@gmail.com>:
> Oleg Kostyuk wrote:
>
>> Seems I did just typo, and instead of installing libnspr4-0d/testng, I
>> installed libnss3-1d/testing. Surprisingly, but this solved my
>> problem.
>
> Gah.
>
> [...]
>> Would you like me to try to install libnss3-1d/stable and libnspr4-0d/testing?
>
> Sure, yes that would be interesting.
>
> Thanks,
> Jonathan



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)

Message #340 received at 647992@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Oleg Kostyuk <cub.uanic@gmail.com>

Cc: 647992@bugs.debian.org

Subject: Re: unrecoverable Aw, Snap! on start up

Date: Thu, 7 Jun 2012 17:09:49 -0500

Oleg Kostyuk wrote:
 
> Seems this way also solve my problem.

Ok, that means the dependency added in 20.0.1132.21~r139451-1 should
take care of squeeze → wheezy upgrades.  Phew.

[...]
> But what was the root of the problem - libnss or libnspr ?..

Chromium's sandbox, which seems to be too complicated for anyone to
understand fully. :/

Thanks,
Jonathan

Send a report that this bug log contains spam.