nacl compiled with SDK 16 stops loading in chrome 17 stable

81 views
Skip to first unread message

Jim

unread,
Feb 12, 2012, 7:34:35 AM2/12/12
to Native-Client-Discuss
I have my nacl vector designer run for more than 1 month without any
problem. After recent chrome update (from Chromium 16 to 17.0.963.46),
the application stops loading nacl module.
Is this a bug or expected as nacl sdk is not formally released yet?
BTW, my application locates in http://www.torapp.info/en/s/torsec.html
.
Thanks

Jim

unread,
Feb 12, 2012, 7:48:32 AM2/12/12
to Native-Client-Discuss
The torapp vector designer works in google-chrome-dev 18.0.1003.1-1,
which I did not upgrade it yet.
So, it appears that when we compiled a nacl module with SDK for chrome
stable, the nacl worked on chrome stable, beta and dev versions.
But when chrome major version got bumped up, it stopped working.

The debug info did not tell anything useful:
[myhost ~]$ [754:761:3199724628:ERROR:bus.cc(261)] Failed to connect
to the bus: Failed to connect to socket /var/run/dbus/
system_bus_socket: No such file or directory
[754:761:3199730370:ERROR:bus.cc(261)] Failed to connect to the bus:
Failed to connect to socket /var/run/dbus/system_bus_socket: No such
file or directory
[27,3057052480:04:19:05.891791] Native Client module will be loaded at
base address 0x0000000000000000
[27,3057052480:04:19:06.423659] NaCl_page_alloc_randomized: 0x6d56f02b
[27,3057052480:04:19:06.424591] NaCl_page_alloc_randomized: hint
0x6d560000
[27,3057052480:04:19:06.424996] NaClMakePcrelThunk: got addr
0x6d560000
[20,3010038592:20:19:06.625366] PluginReverseInterface::ReportCrash
[20,3010038592:20:19:06.628462] PluginReverseInterface::ReportCrash:
invoking CB

Jim

unread,
Feb 12, 2012, 9:47:39 AM2/12/12
to Native-Client-Discuss
The nacl works in linux x86_64 Chromium 17 stable version.(with linux
kernel 3.1.5-1)
The problem happened in my linux i686 Chromium 17 stable version. (the
kernel is linux 3.0, kernel is too old?)

Nick Bray

unread,
Feb 13, 2012, 4:28:10 PM2/13/12
to native-cli...@googlegroups.com
I am able to run it in a 32-bit browser on a 64-bit machine for a recent dev build.  Not the same repro case, but close enough to suggest there is something odd going on.  My first instinct is that one of the PPAPI dev interfaces you are using has changed, but I couldn't tell you why that could only affect the 32-bit version.


You'll need to dig deeper.  

What does the .lastError attribute of embed tag say? e.g. type this in the JavaScript console:
document.getElementById('torsec').lastError;

Does the problem go away if you put null pointer checks around your use of dev interfaces?

Does the problem go away when you compile it with a newer SDK?  (This would be a problem we'd need to fix: things compiled with an older SDK should keep working.)


--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.


Jim

unread,
Feb 14, 2012, 2:57:09 AM2/14/12
to Native-Client-Discuss
What is wierd is that the nacl also worked in Windows. So the problem
seems in linux i686 build of Chromium 17?
If any one of dev API was missing, it would crash in all versions of
Chrome.
I will just wait for a new 32bit linux Chrome version to test.
Thanks for help.

Nick Bray

unread,
Feb 14, 2012, 1:07:22 PM2/14/12
to native-cli...@googlegroups.com, David Meyer
Another thing to check is uninitialized variables.  They may behave differently for different variations (Chrome, the OS, etc).  I've cced in David, who has recently run into this kind of problem.

David Meyer

unread,
Feb 14, 2012, 7:29:55 PM2/14/12
to Nick Bray, native-cli...@googlegroups.com
I did have a similar problem. In my case it was caused by an un-initialized boolean in my plugin instance. I was seeing failures on some versions of Chrome, but not on others.

I wouldn't jump to conclusions though. The only way to be sure is to debug it.

- pdox

Alan Wolfe

unread,
Feb 14, 2012, 7:33:53 PM2/14/12
to native-cli...@googlegroups.com
I'm pretty sure there's a way to compile a program to dirty allocated memory and the stack to help find this stuff.  Can't remember the option off the top of my head but might be worth taking a look as it may help you reproduce this problem more reliably in your prefered dev environment

spoony

unread,
Feb 18, 2012, 8:22:40 PM2/18/12
to Native-Client-Discuss
Manually checked the code before crashing for uninitialized variable.
and I also used cppcheck and did not find any uninitialized variable.
The nacl module crashed pretty early before really doing anything in
my code.
I will just wait another version of Chromium to see what will happen.
Thank you all for reminding me the possibility of un-initialized
variable, and it seems to be.

Egor Pasko

unread,
Feb 21, 2012, 5:17:14 AM2/21/12
to native-cli...@googlegroups.com
On Sun, Feb 19, 2012 at 5:22 AM, spoony <jamesf...@gmail.com> wrote:
> Manually checked the code before crashing for uninitialized variable.
> and I also used cppcheck and did not find any uninitialized variable.
> The nacl module crashed pretty early before really doing anything in
> my code.
> I will just wait another version of Chromium to see what will happen.
> Thank you all for reminding me the possibility of un-initialized
> variable, and it seems to be.

can you, please, make a small reproducer that runs on Chromium 16 and
crashes on Chromium 17?

--
Egor Pasko

Jim

unread,
Mar 12, 2012, 3:38:35 AM3/12/12
to native-cli...@googlegroups.com
naclbox.com games crashed at the same stage for chrome 17 linux x86_32 versions too.
On chrome 19 dev linux 32bit version, it works well.

As a different finding, latest chrome 17 stable and 19 dev linux 64bit version has some subtle crash too (crash in different places, definitely a different bug),
Chrome 19 dev linux 32 bit version works well.
I will provide more info when available.
Reply all
Reply to author
Forward
0 new messages