Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2049 closed bug (invalid)

Mozilla applications fail to discover application signature

Reported by: mmadia Owned by: axeld
Priority: normal Milestone: R1
Component: - General Version: R1/pre-alpha1
Keywords: Cc: tqh
Blocked By: Blocking:
Platform: All


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:

Mozilla function private char *GetAppSig :

Change History (8)

comment:1 by tqh, 12 years ago

Cc: tqh added

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.

comment:2 by tqh, 12 years ago

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

To get current port ID we use methods PR_GetCurrentThread() from NSPR (NS runtime kit):

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,*)):

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

comment:4 by bonefish, 12 years ago

Resolution: invalid
Status: newclosed

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

comment:5 by axeld, 12 years ago

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

comment:6 by anevilyak, 12 years ago

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.

comment:7 by tqh, 12 years ago

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.

comment:8 by tqh, 12 years ago

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.

Note: See TracTickets for help on using tickets.