Mozilla applications fail to discover application signature

[mmadia]

Mozilla applications that have unique AppSigs can be run concurrently in BeOS. In Haiku, even though the apps have recognized and unique AppSigs, they fail to discover them during runtime. This is noticed by one mozilla application terminating one that is already open.

discussion at bezilla: ​http://community.livejournal.com/bezilla/276300.html

Mozilla function private char *GetAppSig : ​http://lxr.mozilla.org/mozilla1.8/source/toolkit/xre/nsNativeAppSupportBeOS.cpp#215

[tqh]

And yes it's ugly :)

We should probably add #ifdefs for different apps in mozilla code instead. And an #error if it's one that we don't know about.

mmadia, I believe this is something that would fit you btw.

[tqh]

Info from Sergei D (fyysik, who is having issues with trac):

We use for internal Mozilla communication BeOS ports, and to have access for those ports from different components and threads we assign to ports name, which must be unique.
For that purpose we're using "current thread" identifier printed in octal form as port name - at stage of port creation. Then when we need somewhere to communicate, we are getting port by find_port - again, using portname created from current thread "number.

• see
  

​http://lxr.mozilla.org/mozilla1.8/source/xpcom/threads/plevent.c#382
​http://lxr.mozilla.org/mozilla1.8/source/widget/src/beos/nsAppShell.cpp#122
​http://lxr.mozilla.org/mozilla1.8/source/widget/src/beos/nsToolkit.cpp#93

To get current port ID we use methods PR_GetCurrentThread() from NSPR (NS runtime kit):
​http://lxr.mozilla.org/mozilla1.8/source/nsprpub/pr/src/bthreads/btthread.c#417

and there is something wrong. I'm not so competent yet to analyze btthreads code, but once I replaced all calls for PR_GetCurrentThread() in 3 places mentioned above, plus this one (NB!!!, may be quite important, as it uses another PR method - mGuiThread = PR_CreateThread(PR_SYSTEM_THREAD,*)):
​http://lxr.mozilla.org/mozilla1.8/source/widget/src/beos/nsToolkit.cpp#231

with simple native find_thread(0) - all started to work as "expected" in Haiku - mozilla apps can now run simultaneously.

[tqh]

Also see ​http://community.livejournal.com/bezilla/282356.html for additional comments.

[bonefish]

This was obviously a bug in the Mozilla (BeOS port) code. You can't expect that object pointers are unique across applications.

[axeld]

Maybe I understood something incorrectly, but they are using thread IDs, not object pointers, right? At least, ports look like this on Firefox under BeOS: 352 p< :75 12 0

[anevilyak]

Actually, it's doing an sprintf using the pointer address of the current thread's PRThread struct. This is incorrect, it should be using the native thread_id contained inside the struct, since, as Ingo pointed out, the PRThread *addr cannot possibly be guaranteed to be unique across apps.

[tqh]

Yes that is incorrect, I think it's as old as the BeOS port btw :) Not really sure if that is enough to explain this problem though. So this bug might get reopened after that fix.

[tqh]

Sergei has confirmed that the PRThread has the same pointer address in the different apps in Haiku. I would have thought this would be quite unlikely, but so it is. Therefore they find the same port.

Fixing so that thread_id is used in the name as it should will probably fix this. BeOS does something different in mem allocation so the apps pointers are in different addresses.