Re: Testing Firefox 62 on sparc64

2018-08-17 Thread John Paul Adrian Glaubitz
On 08/17/2018 12:20 PM, Romain Dolbeau wrote:
> 2018-08-09 14:50 GMT+02:00 John Paul Adrian Glaubitz
> :
>> Did you install the debug package so we can see where it actually
>> crashes in ProcessExecutableMemory.cpp?
> 
> With 62.0~b16-1 on my t5120 (tunneled X11 - dunno if it changes the
> behavior), running with the dbgsym package under gdb:
> 
> #
> Thread 1 "firefox" received signal SIGBUS, Bus error.
> HashIIDPtrKey (key=0x80010a425aec )
> at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:26
> 26  /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:

This is exactly this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1434726

The patch is trivial:

diff --git a/js/xpconnect/src/XPCMaps.cpp b/js/xpconnect/src/XPCMaps.cpp
index bb99b9f8c034..837d5d78970f 100644
--- a/js/xpconnect/src/XPCMaps.cpp
+++ b/js/xpconnect/src/XPCMaps.cpp
@@ -23,7 +23,7 @@ using namespace mozilla;
 static PLDHashNumber
 HashIIDPtrKey(const void* key)
 {
-return HashGeneric(*((uintptr_t*)key));
+return HashGeneric(((nsID*)key)->m0);
 }

 static bool

but not accepted upstream. We have to take a different approach using memcpy().

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Testing Firefox 62 on sparc64

2018-08-17 Thread Romain Dolbeau
2018-08-09 14:50 GMT+02:00 John Paul Adrian Glaubitz
:
> Did you install the debug package so we can see where it actually
> crashes in ProcessExecutableMemory.cpp?

With 62.0~b16-1 on my t5120 (tunneled X11 - dunno if it changes the
behavior), running with the dbgsym package under gdb:

#
Thread 1 "firefox" received signal SIGBUS, Bus error.
HashIIDPtrKey (key=0x80010a425aec )
at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:26
26  /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:
No such file or directory.
(gdb)
(gdb) bt
#0  HashIIDPtrKey (key=0x80010a425aec )
at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:26
#1  0x80010690aed4 in PLDHashTable::ComputeKeyHash (
aKey=0x80010a425aec ,
this=0x7440140)
at /build/firefox-qTMIsZ/firefox-62.0~b16/xpcom/ds/PLDHashTable.cpp:586
#2  PLDHashTable::Add (this=0x7440140,
aKey=0x80010a425aec )
at /build/firefox-qTMIsZ/firefox-62.0~b16/xpcom/ds/PLDHashTable.cpp:586
#3  0x80010701a140 in IID2NativeInterfaceMap::Add
(iface=0x74abfa0, this=0x7440140)
at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.h:245
(...)
#

>From the source package, the relevant source bit would be:

#
static PLDHashNumber
HashIIDPtrKey(const void* key)
{
return HashGeneric(*((uintptr_t*)key));
}
#
Line 26 being the return.

#
(gdb) disassemble
Dump of assembler code for function HashIIDPtrKey(void const*):
=> 0x800106fe206c <+0>: ldx  [ %o0 ], %g3
   0x800106fe2070 <+4>: add  %g3, %g3, %g2
   0x800106fe2074 <+8>: srlx  %g3, 0x20, %g4
   0x800106fe2078 <+12>:add  %g2, %g3, %g1
(...)
(gdb) print (uintptr_t*)key
$9 = (uintptr_t *) 0x80010a425aec 
#

So, yet another function that doesn't bother to check for alignment,
it seems... that pointer is aligned on 4 bytes, but not 8.

Cordially,

-- 
Romain Dolbeau



Re: Testing Firefox 62 on sparc64

2018-08-09 Thread John Paul Adrian Glaubitz
On 08/09/2018 04:54 PM, Gregor Riepl wrote:
>> Yes, I know. But that means extra work with Vnc unless I want the pain that
>> is X11 tunneling.
> 
> ssh -X doesn't work for you?
> It's usually relatively painless... usually.

Of course, it does. It's just awfully slow.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Testing Firefox 62 on sparc64

2018-08-09 Thread Gregor Riepl
> Yes, I know. But that means extra work with Vnc unless I want the pain that
> is X11 tunneling.

ssh -X doesn't work for you?
It's usually relatively painless... usually.



Re: Testing Firefox 62 on sparc64

2018-08-09 Thread John Paul Adrian Glaubitz
On 08/09/2018 03:25 PM, Gregor Riepl wrote:
>> It's an assertion that's triggered from here:
>>
>>> https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp
>>
>> Did you install the debug package so we can see where it actually
>> crashes in ProcessExecutableMemory.cpp?
> 
> Yes, otherwise the backtrace wouldn't have included _any_ information at
> all... Seems like it's still not very useful.
> Perhaps I need to launch FF with special parameters to get meaningful output?

Yes, but we're still missing the line numbers.

>> Otherwise, I'll have to build from source and debug from there.
> 
> You could run FF in Xvfb or via X11 tunneling if you don't have a workstation
> with a screen, you know. ;)

Yes, I know. But that means extra work with Vnc unless I want the pain that
is X11 tunneling.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Testing Firefox 62 on sparc64

2018-08-09 Thread Gregor Riepl
> It's an assertion that's triggered from here:
> 
>> https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp
> 
> Did you install the debug package so we can see where it actually
> crashes in ProcessExecutableMemory.cpp?

Yes, otherwise the backtrace wouldn't have included _any_ information at
all... Seems like it's still not very useful.
Perhaps I need to launch FF with special parameters to get meaningful output?

> Otherwise, I'll have to build from source and debug from there.

You could run FF in Xvfb or via X11 tunneling if you don't have a workstation
with a screen, you know. ;)

I tried both on the machine's desktop and via ssh -X, resulting in the same
crash, by the way.



Re: Testing Firefox 62 on sparc64

2018-08-09 Thread John Paul Adrian Glaubitz
On 08/09/2018 02:41 PM, Gregor Riepl wrote:
>> Could someone with a desktop installed on their sparc64 box please
>> test the firefox package from experimental and check whether the
>> alignment-related crash is still present [1]?
> 
> I have bad news, unfortunately. :(
> 
> firefox crashes (reproduceably) right after launch, and it seems it might be
> something else:
> 
> Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
> MOZ_CrashOOL (aLine=, aReason=0xf8010a832550
> "js::jit::InitProcessExecutableMemory() failed")
> at /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp:33
> 33  in /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp

It's an assertion that's triggered from here:

> https://hg.mozilla.org/mozilla-central/file/tip/js/src/jit/ProcessExecutableMemory.cpp

Did you install the debug package so we can see where it actually
crashes in ProcessExecutableMemory.cpp?

Otherwise, I'll have to build from source and debug from there.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Testing Firefox 62 on sparc64

2018-08-09 Thread Gregor Riepl
> Could someone with a desktop installed on their sparc64 box please
> test the firefox package from experimental and check whether the
> alignment-related crash is still present [1]?

I have bad news, unfortunately. :(

firefox crashes (reproduceably) right after launch, and it seems it might be
something else:

Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
MOZ_CrashOOL (aLine=, aReason=0xf8010a832550
"js::jit::InitProcessExecutableMemory() failed")
at /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp:33
33  in /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp
(gdb) bt
#0  0x01005948 in MOZ_CrashOOL(int, char const*) (aLine=, aReason=0xf8010a832550 "js::jit::InitProcessExecutableMemory() 
failed")
at /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp:33
#1  0xf80106977070 in NS_InitXPCOM2.part.338 () at 
/usr/lib/firefox/libxul.so
#2  0xf801094c35f0 in ScopedXPCOMStartup::Initialize() () at
/usr/lib/firefox/libxul.so
#3  0xf801094cbcac in XREMain::XRE_main(int, char**,
mozilla::BootstrapConfig const&) () at /usr/lib/firefox/libxul.so
#4  0xf801094cc194 in XRE_main(int, char**, mozilla::BootstrapConfig
const&) () at /usr/lib/firefox/libxul.so
#5  0x01006210 in do_main(int, char**, char**) (argc=,
argv=0x7fef4a8, envp=0x7fef4b8)
at
/build/firefox-mXaCXs/firefox-62.0~b10/build-browser/dist/include/mozilla/UniquePtr.h:326
#6  0x01005a98 in main(int, char**, char**) (argc=,
argv=0x7fef4a8, envp=0x7fef4b8)
at /build/firefox-mXaCXs/firefox-62.0~b10/browser/app/nsBrowserApp.cpp:311
(gdb) info threads
  Id   Target Id Frame
* 1Thread 0xf80100042740 (LWP 1552) "firefox" MOZ_CrashOOL
(aLine=, aReason=0xf8010a832550
"js::jit::InitProcessExecutableMemory() failed")
at /build/firefox-mXaCXs/firefox-62.0~b10/mfbt/Assertions.cpp:33
  2Thread 0xf8010dd6f910 (LWP 1573) "Gecko_IOThread"
0xf801009c358c in epoll_wait (epfd=, events=0x71ea600,
maxevents=,
timeout=) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30



Re: Testing Firefox 62 on sparc64

2018-08-08 Thread Gregor Riepl
> Could someone with a desktop installed on their sparc64 box please
> test the firefox package from experimental and check whether the
> alignment-related crash is still present [1]?

Many thanks for building it, I will try the package later tonight!

> You also should pin down experimental in your /etc/apt/preferences:
> 
> Package: *
> Pin: release a=experimental
> Pin-Priority: 1

Is that really necessary?
I thought experimental had a very low priority by default...