pexe on arm sometimes never finish translate

[Russell Valentine]

I have a pretty large pexe ~4 Megs. It takes some time for it to load up
(translate). On arm sometimes it gets to the end and I never get a load
callback from the NaClProcessManager. If I just pretend it finished
loading at that point, it doesn't run. I've only see this problem on arm
not Intel. My solution right now is to set a timeout and if I didn't get
the load callback I call chrome.runtime.reload() and try again.
Eventually after a couple reloads it ends up loading, I get the callback
and everything is fine.

Anyone run into this issue?


Russell Valentine

[Victor Khimenko]

On Thu, Feb 26, 2015 at 12:18 AM, Russell Valentine <russell....@gmail.com> wrote:

I have a pretty large pexe ~4 Megs. It takes some time for it to load up (translate). On arm sometimes it gets to the end and I never get a load callback from the NaClProcessManager. If I just pretend it finished loading at that point, it doesn't run. I've only see this problem on arm not Intel. My solution right now is to set a timeout and if I didn't get the load callback I call chrome.runtime.reload() and try again. Eventually after a couple reloads it ends up loading, I get the callback and everything is fine.

Does it work reliably on x86-32? PNaCl translator itself has 4GiB address space on x86-64 but only 1GiB on x86-32 and arm...

[Jan Voung]

It should be able to handle a 4MB pexe in 1GiB of address space. Under ChromeOS you can open the crosh (with ctrl-alt-t) and use "top" to look for a process with the name "nacl_helper" and watch its RES memory usage to confirm that it completes in under 1GiB.

Otherwise, the chrome task manager gives a slightly more precise name to the process than "nacl_helper". The translation process currently involves two "chrome://pnacl-translator/arm/..." tasks under the chrome task manager, one after the other. The two are "pnacl-llc.nexe" and "ld.nexe". Which one hangs?

Is this reproducible if you run the commandline tool "pnacl-translate" from the SDK?

What version of ChromeOS / NaCl SDK?

 

Anyone run into this issue?

 

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

[Russell Valentine]

Using top I do not see anything taking any more than a few percent of memory. The nacl_helper_bootstrap /opt/google/chrome/nacl_helper takes lots of CPU then it stops as if it was done even though I don't get the loaded event.

ChromeOS version 40.0.2214.114

I was also mistaken, it happens on both intel x86_64, and arm on ChromeOS. I've never seen it happen on x86_64 Chrome in Linux.

This is actually a prebuilt pexe build from the naclports continuous builder:
http://gsdview.appspot.com/naclports/builds/pepper_41/trunk-247-g574856f/publish/python/pnacl/python.pexe

I tried nacl_translate with pepper_40 sdk it seems to finish everytime.

You think this might be because I'm using something compiled using pepper_41? These later builds are the only ones I've been able to get to work the way I want. I'm just having this last intermittent loading problem.

Thanks for your replies.

[Jan Voung]

Do any errors/warning messages show up in the javascript console? When you say that nacl_helper stops in top, do you mean it exits or gets stuck?

Just to check, is your x86_64 Chrome in Linux (where things do work compared to ChromeOS x86_64), also version 40, or is it on 41?

Thanks for the link. So loading http://commondatastorage.googleapis.com/naclports/builds/pepper_41/trunk-247-g574856f/publish/python/pnacl/index.html should trigger loading that pexe and help reproduce the problem then? I don't have an arm chromebook with 40 with me right now, but can try it later.

Sometimes running apps compiled with pepper_N+1 on chrome N will fail... if there is a new API pepper N+1 requests that chrome N doesn't support, but that should be deterministic.

- Jan

 

On Thu, Feb 26, 2015 at 12:54 PM Russell Valentine <russell....@gmail.com> wrote:

Using top I do not see anything taking any more than a few percent of memory. The nacl_helper_bootstrap /opt/google/chrome/nacl_helper takes lots of CPU then it stops as if it was done even though I don't get the loaded event.

ChromeOS version 40.0.2214.114

I was also mistaken, it happens on both intel x86_64, and arm on ChromeOS. I've never seen it happen on x86_64 Chrome in Linux.

This is actually a prebuilt pexe build from the naclports continuous builder:
http://gsdview.appspot.com/naclports/builds/pepper_41/trunk-247-g574856f/publish/python/pnacl/python.pexe

I tried nacl_translate with pepper_40 sdk it seems to finish everytime.

You think this might be because I'm using something compiled using pepper_41? These later builds are the only ones I've been able to get to work the way I want. I'm just having this last intermittent loading problem.

Thanks for your replies.

On Thu, Feb 26, 2015 at 12:23 PM, 'Jan Voung' via Native-Client-Discuss <native-client-discuss@googlegroups.com> wrote:

On Wed, Feb 25, 2015 at 3:06 PM Victor Khimenko <kh...@chromium.org> wrote:

On Thu, Feb 26, 2015 at 12:18 AM, Russell Valentine <russell....@gmail.com> wrote:

I have a pretty large pexe ~4 Megs. It takes some time for it to load up (translate). On arm sometimes it gets to the end and I never get a load callback from the NaClProcessManager. If I just pretend it finished loading at that point, it doesn't run. I've only see this problem on arm not Intel. My solution right now is to set a timeout and if I didn't get the load callback I call chrome.runtime.reload() and try again. Eventually after a couple reloads it ends up loading, I get the callback and everything is fine.

Does it work reliably on x86-32? PNaCl translator itself has 4GiB address space on x86-64 but only 1GiB on x86-32 and arm...

It should be able to handle a 4MB pexe in 1GiB of address space. Under ChromeOS you can open the crosh (with ctrl-alt-t) and use "top" to look for a process with the name "nacl_helper" and watch its RES memory usage to confirm that it completes in under 1GiB.

Otherwise, the chrome task manager gives a slightly more precise name to the process than "nacl_helper". The translation process currently involves two "chrome://pnacl-translator/arm/..." tasks under the chrome task manager, one after the other. The two are "pnacl-llc.nexe" and "ld.nexe". Which one hangs?

Is this reproducible if you run the commandline tool "pnacl-translate" from the SDK?

What version of ChromeOS / NaCl SDK?

Anyone run into this issue?

 

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.
To post to this group, send email to native-client-discuss@googlegroups.com.

Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.
To post to this group, send email to native-client-discuss@googlegroups.com.

Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.
To post to this group, send email to native-client-discuss@googlegroups.com.

[Russell Valentine]

About nacl_helper, I just see it drop from the top of cpu usage of top. It stops using cpu at least.

Yes x86_64 on Chrome is also version 40:
40.0.2214.115

I will write a script to help me see more of the the nacl_helper process is doing, if it exits or not, as there are a lot of nacl_helpers to keep track of. Yes running that build should reproduce the problem, but please note it is not happening every time, so if it doesn't happen I touch the pexe to make it translate it again and try again. This is an excellent idea and I too will try exactly that, without all my other junk in an effort to further isolate.

I did see it on an x86_64 intel chromebook too, so it isn't isolated to just arm like I originally thought.

Thank you.

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.

[Russell Valentine]

I did some more experimenting on the arm chromebook.

Summary:

* It does sometimes not load with the linked python bundle. I'd estimate it does it around 10% of the time (similar to my own).

* Ran 'ps auxww|grep nacl' every second and wrote it to a log (logs attached)

** success.log is one that loaded correctly
** failure.log is one that did not.

* From the logs it looks like the process quits in both cases (not hangs).

* I don't really see anything different between the two besides what is probably the translated process that does not run in the failure one.

* I see no errors in the javascript console (background or index).

* chrome://system ui_log Doesn't show anything special when it fails compared to success that I can tell.

failure.log:

Translator, pid 26259

success.log:

Translator, pid 21125

translated process, pid 21520 (I'm assuming)

[Russell Valentine]

Later today I saw this in the chrome://system ui_log. I did not see this the other times, I don't know if it is related.

[1962:2177:0227/143710:ERROR:pnacl_host.cc(448)] TranslationFinished: TranslationID 90,37223589 not found.

Thanks.

[Russell Valentine]

Using the papper_40 sdk I rebuilt the python.pexe and still saw this behaviour. Now that I am able to build it correctly I'm probably just going to try to use the nexe's to work around this issue.