Re: [native-client-discuss] Qt nacl broken with chrome Version 25.0.1323.1 canary

[Brad Chen]

There may be some stability issues with Canary at this time, so thank you for reporting this. Please see crbug.com/116317 for more details. The engineers in question aren't in yet this morning; in the mean time if you could confirm that only Canary is broken that would help us narrow things down.

Brad

On Mon, Nov 12, 2012 at 2:41 AM, Alexandre Barreira <abar...@gmail.com> wrote:

Hi all,

Qt for Nacl worked like a charm until this morning, before canary got updated to 25.0.1323.1. Chrome displays the top bar "A plugin [path to nmf] is not responding."

One can repro the issue by going to this page http://pencil.qtapps.net/ with the mentioned version.

Any idea on what's wrong with this new version? I couldn't find the changeset..

Cheers,

Alexandre

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/MKEpQqjIVcQJ.
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.

[Bill Budge]

I suspect that your app is using 'Dev' interfaces which haven't been proxied yet. In the meantime you can use the --enable-nacl-srpc-proxy to keep developing.

I will try to get the missing 'Dev' interfaces in today.

[Bill Budge]

Actually, what I see when I run the app is that PPP_Instance_1_1 isn't found. We should fall back to 1_0 but perhaps that is broken. I'll check.

I don't know how hard it would be to implement 1_1 in your app but perhaps that would be enough to get things working.

[David Michael]

I'm getting the following in the JavaScript console:
Failed to load resource: the server responded with a status of 403 (Forbidden) http://pencil.qtapps.net/x86-64/runnable-ld.so

You might need to tinker with your server settings for me to be able to reproduce? Not sure if the symptom Bill is seeing is just because the nexe didn't load, or if he's getting further than I am.

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/9X47Ka86OKsJ.

[Alexandre Barreira]

I can at least confirm that it still works with the dev channel version.

Brad

To unsubscribe from this group, send email to native-client-discuss+unsub...@googlegroups.com.

[Alexandre Barreira]

The thing is that, as far as i known, qt nacl is developed against pepper 19 (last time i tried building with pepper 23 i got some opengl-related errors..). If i'm not mistaken, pepper 19 doesn't contain PPB_Instance;1.1, right?

[Alexandre Barreira]

I don't get such error, but the issue indeed happens while loading dyn libs. I doubt this is network related, since I experienced the same issue with a plugin loaded through an unpacked extension (i just posted the link to this qt example for you to repro the issue, i don't host it)

To unsubscribe from this group, send email to native-client-discuss+unsub...@googlegroups.com.

[David Michael]

On Mon, Nov 12, 2012 at 3:09 PM, Alexandre Barreira <abar...@gmail.com> wrote:

The thing is that, as far as i known, qt nacl is developed against pepper 19 (last time i tried building with pepper 23 i got some opengl-related errors..). If i'm not mistaken, pepper 19 doesn't contain PPB_Instance;1.1, right?

Bill's talking about PPP_Instance;1.1.

That means Pepper is calling QT's GetInterface function and asking for "PPP_Instance;1.1", and getting a NULL result instead of a valid pointer. This might happen if the NaCl/Pepper runtime was unable to load the necessary shared objects to run the app (which is what I'm still observing).

On Monday, November 12, 2012 9:18:48 PM UTC+1, Bill Budge wrote:

Actually, what I see when I run the app is that PPP_Instance_1_1 isn't found. We should fall back to 1_0 but perhaps that is broken. I'll check.

I don't know how hard it would be to implement 1_1 in your app but perhaps that would be enough to get things working.

On Monday, November 12, 2012 11:37:21 AM UTC-8, Bill Budge wrote:

I suspect that your app is using 'Dev' interfaces which haven't been proxied yet. In the meantime you can use the --enable-nacl-srpc-proxy to keep developing.

I will try to get the missing 'Dev' interfaces in today.

On Monday, November 12, 2012 2:41:36 AM UTC-8, Alexandre Barreira wrote:

Hi all,

Qt for Nacl worked like a charm until this morning, before canary got updated to 25.0.1323.1. Chrome displays the top bar "A plugin [path to nmf] is not responding."

One can repro the issue by going to this page http://pencil.qtapps.net/ with the mentioned version.

Any idea on what's wrong with this new version? I couldn't find the changeset..

Cheers,

Alexandre

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/ryJWdDik_UsJ.

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.

[Bill Budge]

Yes, I'm getting this even on Stable Channel now (Version 23.0.1271.64 m) on Windows.

To unsubscribe from this group, send email to native-client-discuss+unsub...@googlegroups.com.

[Bill Budge]

I was mistaken about that error. The interface is found successfully. However, it seems to get called before the proxy is started up. I can't debug on Windows right now because I'm getting a 403 when loading the first dynamic library.

To unsubscribe from this group, send email to native-client-discuss+unsub...@googlegroups.com.

[Alexandre Barreira]

Well then maybe the behavior I experienced with the served plugin and the extension one is not caused by the same issue.. but i'm still able to load the pencil app with chrome dev.

[David Michael]

Note that the .sos are coming from you cache (see under the Size column).

You might try --incognito, or --user-data-dir=(some temporary directory) to see if you can reproduce the 403.

[Alexandre Barreira]

Yes, (i believe) that's because these files are loaded from an unpacked extension. Nevertheless, launching chrome from command line allowed me to catch the following log when trying to load the pencil app or my extension:

[12241,2954530816:00:23:15.147127] Native Client module will be loaded at base address 0x0000000008cb4000

[12241,2954899456:00:23:33.872834] Invalid open flags 0100000, ignoring extraneous bits

QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed

#### QPlatformIntegrationFactory::create "pepper" () "/platforms/" 

QFileSystemEngine::currentPath: stat(".") failed

QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed

QFileSystemEngine::currentPath: stat(".") failed

QFileSystemEngine::currentPath: stat(".") failed

#### QPlatformIntegrationFactory::createed "pepper" 

QFileSystemEngine::currentPath: stat(".") failed

QFileSystemEngine::currentPath: stat(".") failed

This plugin does not support propagateSizeHints()

This plugin does not support propagateSizeHints()

QPepperCompositor: No frame buffer set

QPepperCompositor: No frame buffer set

QPepperCompositor: No frame buffer set

To unsubscribe from this group, send email to native-client-discuss+unsubscri...@googlegroups.com.

[Alexandre Barreira]

Well forget about these logs since they also appear when the plugin is successfully launched..

[Morten Johan Sørvig]

The OpenGL compile errors are caused by the new GLES2_GET_FUN define introduced in Pepper 20, which rewrites gl function names like glActiveTexture to GLES2ActiveTexture or gles2::GetGLContext()->ActiveTexture.

Qt #undefs any gl function defines and tries to call the functions directly, resulting in a compile error since glActiveTexture no longer exist. I can't remove the #undef either, since we have a Qt wrapper function is named QOpenGLFunctions::glActiveTexture which I believe the C preprocessor will happily mangle for me.

I have a workaround in progress, in the mean time stay on Pepper 19.

- Morten

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/ryJWdDik_UsJ.

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.

[Bill Budge]

I've been debugging this further. I can load all the .so files on Mac without any 403's (perhaps 64 bit files are missing on the server?) and the problem is that our IRT plugin proxy code isn't started. So the renderer sends the message to start the proxy and then hangs waiting for a reply that never comes.

This means your app is likely fine and that we have a startup issue.

[Bill Budge]

More debugging and we found the problem.

The app is trying to load parts of the old SRPC proxy (libppruntime.so, libsrpc.so, etc.) which won't work with the new proxy. I'm not sure how this works with the old proxy but I can see these files listed in your manifest (.nmf) file and the loads fail.

[Morten Johan Sørvig]

Hi, I've looked into this a bit and been able to reduce the number of .so's Qt links against. (Looks like the libsrpc.so linking was purely accidental.)

I'm left with this set: -lppruntime -lppapi -lppapi_cpp

The reason for requiring libppruntime is that Qt implements main() and calls PpapiPluginMain() during initialisation. Is it possible to use this pattern with the new proxy?

Thanks,

Morten

On Wed, Nov 14, 2012 at 12:06 AM, Bill Budge <bbu...@google.com> wrote:

More debugging and we found the problem.

The app is trying to load parts of the old SRPC proxy (libppruntime.so, libsrpc.so, etc.) which won't work with the new proxy. I'm not sure how this works with the old proxy but I can see these files listed in your manifest (.nmf) file and the loads fail.

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

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/a-HDMnjlPsAJ.

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.

[Mark Seaborn]

On 20 November 2012 13:37, Morten Johan Sørvig <mso...@gmail.com> wrote:

Hi, I've looked into this a bit and been able to reduce the number of .so's Qt links against. (Looks like the libsrpc.so linking was purely accidental.)

I'm left with this set: -lppruntime -lppapi -lppapi_cpp

You shouldn't be linking against libppruntime:  that is a Chromium-internal library, and if it was included in an SDK, that was a mistake.  You should link against libppapi instead.
 

The reason for requiring libppruntime is that Qt implements main() and calls PpapiPluginMain() during initialisation. Is it possible to use this pattern with the new proxy?

Yes.  libppapi defines PpapiPluginMain().

Cheers,
Mark