openblas crashes firefox #2030
Comments
|
What is your hardware ? And is there anything in the firefox output that suggests which component of firefox has a dependency on OpenBLAS ? Also does it work if you do not use LD_PRELOAD (there was a recent issue with sage where it appeared that preloading openblas led to a problem with a signal handler in the python/cython code) |
|
hardware is Intel® Core™ i7-7820HK CPU @ 2.90GHz × 8 I don't know how to get additional FF crash info other than the exceptions posted. No it doesn't crash without LD_PRELOAD or LD_PRELOAD older versions of openblas (or intel-mkl) |
|
How do you use BLAS in Firefox? Firefox does not even load native libraries nowadays like java etc. |
|
Must be some third-party plugin for firefox, either for some computationally expensive operation - why would one need BLAS or LAPACk to view websites - or something that creates an indirect dependency, |
|
Problem starting with 0.3.4 at least matches #1936 |
|
what is gdb? |
|
GNU debugger that shows backtraces, it is available as package on any linux |
|
Do you preload OpenBLAS specifically for firefox, or do you do this globally for some other software and just happened to notice that firefox now crashes ? |
|
No, not specifically for Firefox, I put it in my .profile for other things and just happened to notice Firefox crashes. |
|
I see. This is probably risky in general, not just with libopenblas. In this particular case I suspect (similar to #1936) that a relatively small change in thread-local memory usage with 0.3.4 changes the minimum stack size requirements of threads subsequently started by firefox. (Possibly due to a bug in the C runtime library, glibc, and not actually in OpenBLAS itself). So if the situation is similar to that other issue, thread creation now fails if a (now too) small stack size is requested, but unlike #1936 there is another bug in firefox (or a plugin) where it does not check if thread creation succeeded, so you get a crash. |
|
@beev does it crash same if you load openblas but without openmp? |
|
openblas was compiled against openmp, I don't know how to load one without the other. |
|
Just compile without any options.... |
|
I have tested by compiling openblas0.3.5 with no option and a fresh Firefox profile with no addon, still crashes immediately. |
|
I cannot get firefox to crash by ld_preload-ing openblas or even various malloc replacements. if backtrace does not hav function names in it, just long hex addresses - while in crashed state, look at the pid-s mentioned and make a copy of /proc//maps to clarify process memory layout. |
|
Can you try if #2039 fixes any? |
|
@brada4 that seems highly unlikely, as the only platform that still defines WHEREAMI is 32bit x86 |
|
Hi openblas compiled without option, Firefox clean profile with no addon. After the last line typing return produces no more output. |
|
Thank you for backtrace already. Martin was right about thread creation failure since the very beginning. My speculation on what happens behind the scenes: Martin knows better on how to build openblas that logs verbosely thread creation I would like to ask for more detailed backtrace of same: |
|
From what we saw in #1936, I think it goes more like this - libopenblas gets preloaded into firefox' address space (although firefox probably does not need it), sets up its default number of threads which since 0.3.4 reserve an additional 8k of thread-local memory within their stack frame. Then firefox tries to create its own worker threads, requesting a stack size that is big enough for their needs but possibly smaller than what OpenBLAS asked for earlier. Now either this gets rejected immediately, or glibc silently deducts the 8k it saw earlier from the requested size - I am still a bit hazy about how thread memory allocation is supposed to work internally, and where glibc goes wrong, but the glibc bug ticket suggests that the bug is on their end. In either case the thread is unable to run, and firefox bombs out as it does not have an error handler set up for this failure case. |
Hi, sorry, this is a bit over my head, can you give me more detailed step by step instructions? firefox-dgb is already installed. |
|
Seems a rather pointless exercise to me anyway, unless a firefox developer was involved. |
|
I don't think it is a firefox problem in particular, I have just reproduced #1936 with sage as well. Who knows how many other programs are affected. More realistic for openblas to fix the problem that originated from it (seems to have started since 0.3.4) |
|
The problem with that is simply that the relevant change in 0.3.4 was made to fix another serious bug, and so far it is not clear (to me at least) that there is anything fundamentally wrong with the changed code. On the other hand, preloading any library is risky as it circumvents regular initialization sequences, and doing an unconditional session-wide LD_PRELOAD of a specialized library is unusual at best. I have kept issue #1936 open on purpose, although that particular case has been "solved" by |
|
believed to be fixed by #2879 (reducing stack requirements for OpenBLAS) |
OS Ubuntu 16.04 64 bit
openblas 0.3.4 and 0.3.5 compiled from source with
I use update-alternatives to switch between openblas and intel-mkl, update-alternatives creates a symlink of libblas to /usr/lib and I sue LD_PRELOAD to preload libblas (whichever that is the default in update-alternatives)
If openblas is used, firefox crashes. Trying to start Firefox from terminal after it crashes got these outputs and it crashes immediately again (FF is up to date 65.01)
This doesn't happen with openblas 0.3.3 and before when compiled and preloaded the same way.
The text was updated successfully, but these errors were encountered: