4 ms·

32 bit Firefox doesn't work anyway. I had an old 32 bit Firefox and didn't change it when I switched to 64 bit installation (I didn't realize). It crashed NON-

by ars 1y ago

32 bit Firefox doesn't work anyway. I had an old 32 bit Firefox and didn't change it when I switched to 64 bit installation (I didn't realize). It crashed NON-STOP. And it would not remember my profile when I shut down, which made the crashes even worse, since I lost anything I was working on. I finally figured out the problem, switched to 64 bit and it was like magic: Firefox actually worked again.

capitainenemo 1y ago
I don't know if you can draw any good conclusions from that on a linux install. Seems just as likely that after your 64 bit install switch, 32 bit libraries it was depending on were missing. Linux distros don't tend to be as obsessive at maintaining full 32 bit support as the Windows world. A better test would be to fire up a 32 bit VM and see if Firefox 32 bit crashed there...
- ars 1y ago
  It's Debian, it can handle 32 bit and 64 bit applications at the same time, and the package manager makes sure you have all the dependencies. I didn't change libraries, it was a gradual switch where you convert applications to 64 bit - and I didn't think to do Firefox, but it wasn't missing 32 bit libraries. It was simply a profile that I'd been continuously using since approx 2004, and it was probably too large to fit in 32 memory anymore, or maybe Firefox itself needed more memory and couldn't map it. (The system had a 64 bit kernel, so it wasn't low on RAM), but 32 bit apps are limited to 2/3/4GB.
  - capitainenemo 1y ago
    Possible I suppose. You can restrict firefox memory usage in the config. Perhaps their dynamic allocation was getting confused by what was available on the 64 bit machine? Still. Why would any 32 bit app even try to allocate more than it actually could handle. I dunno. I'm still inclined to think missing libs (or out of date libs) - but hard to say without a bit more detail on the crash. Did anything show up in .xsession-errors / stderr ? Were you able to launch it in a clean profile? Were the crashes visible in about:crashes for the profile when launched in 64 bit? I suppose it doesn't matter too much at this point...
    - ars 1y ago
      See my reply here: https://news.ycombinator.com/item?id=45173661 https://news.ycombinator.com/item?id=45173661
- sfink 1y ago
  If they made it as far as being able to lose something they were working on, then it's less likely to have been a missing library problem. But I don't know what it was; people do successfully run Firefox on 32-bit Linux. Firefox does have problems with old profiles, though. I could easily see crud building up there. I don't think Firefox is very good about clearing it out (unless you do the refresh profile thing). You could maybe diagnose it with about:memory, if you were still running that configuration.
  - ars 1y ago
    I tried about:memory, I did not find anything useful. See also my reply here: https://news.ycombinator.com/item?id=45173661 https://news.ycombinator.com/item?id=45173661 (I'm no longer running it, I switched to 64 bit and was VERY happy to no longer have crashes.) I technically could re-install the 32 bit one, and try it, but honestly, I don't really want to!
- rst 1y ago
  If the libraries were missing entirely, I'm not sure 32-bit Firefox would even start. But if they were present and nothing was keeping them updated (pretty likely on an otherwise 64-bit system), they'd pretty likely become out of date -- which could certainly explain spurious crashes.
  - capitainenemo 1y ago
    Fair point, although Firefox also launches subprocesses, and I don't know if those use same libraries as the main process. And I also don't know if it dynamically loads supporting libs after launch.
  - ars 1y ago
    No, this is Debian, it keeps the 32 bit libraries just as in-date as the 64 bit ones. It can handle having both at the same time.
bgirard 1y ago
Did you attach the debugger and see what it was crashing on? From when I used to work on performance and reliability at Mozilla, these types of user specific crashes were often caused by faulty system library or anti-virus like software doing unstable injections/hooks. Any kind of frequent crashes were also easier to reproduce and as a result fix.
- ars 1y ago
  Here is one of the crash reports: https://crash-stats.mozilla.org/report/index/15999dc2-9465-4592-9ec5-b25e80250908 https://crash-stats.mozilla.org/report/index/15999dc2-9465-4... (I happened to have an un-subitted one which I just submitted, all the other ones I submitted are older than 6 months and have been purged.) It would crash in random spots, but usually some kind of X, GLX, EGL or similar library. But I don't think it was GLX, etc, because it also didn't save my profile except very very rarely, which was actually a much worse problem!! (This crash is from a long time ago, hence the old Firefox version.)
  - capitainenemo 1y ago
    Is that proprietary nvidia driver stuff in the stack trace?
    - ars 1y ago
      Yes, without it YouTube plays at like 5fps. If it matters, that proprietary nvidia stuff is still there with the 64 bit which is rock solid. Also, I tried disabling EGL in the 32 bit with no effect on the crashing.
      - capitainenemo 1y ago
        hm. would be nice to have one of the traces with egl disabled. but I guess this is not really my problem to debug, esp since it's such an edge case (32 bit on 64 bit machine + nvidia blob) and given mozilla is abandoning support anyway.
  - 1y ago

by ars 1y ago

capitainenemo 1y ago

I don't know if you can draw any good conclusions from that on a linux install. Seems just as likely that after your 64 bit install switch, 32 bit libraries it was depending on were missing. Linux distros don't tend to be as obsessive at maintaining full 32 bit support as the Windows world. A better test would be to fire up a 32 bit VM and see if Firefox 32 bit crashed there...

ars 1y ago
It's Debian, it can handle 32 bit and 64 bit applications at the same time, and the package manager makes sure you have all the dependencies. I didn't change libraries, it was a gradual switch where you convert applications to 64 bit - and I didn't think to do Firefox, but it wasn't missing 32 bit libraries. It was simply a profile that I'd been continuously using since approx 2004, and it was probably too large to fit in 32 memory anymore, or maybe Firefox itself needed more memory and couldn't map it. (The system had a 64 bit kernel, so it wasn't low on RAM), but 32 bit apps are limited to 2/3/4GB.
- capitainenemo 1y ago
  Possible I suppose. You can restrict firefox memory usage in the config. Perhaps their dynamic allocation was getting confused by what was available on the 64 bit machine? Still. Why would any 32 bit app even try to allocate more than it actually could handle. I dunno. I'm still inclined to think missing libs (or out of date libs) - but hard to say without a bit more detail on the crash. Did anything show up in .xsession-errors / stderr ? Were you able to launch it in a clean profile? Were the crashes visible in about:crashes for the profile when launched in 64 bit? I suppose it doesn't matter too much at this point...
  - ars 1y ago
    See my reply here: https://news.ycombinator.com/item?id=45173661 https://news.ycombinator.com/item?id=45173661
sfink 1y ago
If they made it as far as being able to lose something they were working on, then it's less likely to have been a missing library problem. But I don't know what it was; people do successfully run Firefox on 32-bit Linux. Firefox does have problems with old profiles, though. I could easily see crud building up there. I don't think Firefox is very good about clearing it out (unless you do the refresh profile thing). You could maybe diagnose it with about:memory, if you were still running that configuration.
- ars 1y ago
  I tried about:memory, I did not find anything useful. See also my reply here: https://news.ycombinator.com/item?id=45173661 https://news.ycombinator.com/item?id=45173661 (I'm no longer running it, I switched to 64 bit and was VERY happy to no longer have crashes.) I technically could re-install the 32 bit one, and try it, but honestly, I don't really want to!
rst 1y ago
If the libraries were missing entirely, I'm not sure 32-bit Firefox would even start. But if they were present and nothing was keeping them updated (pretty likely on an otherwise 64-bit system), they'd pretty likely become out of date -- which could certainly explain spurious crashes.
- capitainenemo 1y ago
  Fair point, although Firefox also launches subprocesses, and I don't know if those use same libraries as the main process. And I also don't know if it dynamically loads supporting libs after launch.
- ars 1y ago
  No, this is Debian, it keeps the 32 bit libraries just as in-date as the 64 bit ones. It can handle having both at the same time.

bgirard 1y ago

Did you attach the debugger and see what it was crashing on? From when I used to work on performance and reliability at Mozilla, these types of user specific crashes were often caused by faulty system library or anti-virus like software doing unstable injections/hooks. Any kind of frequent crashes were also easier to reproduce and as a result fix.

ars 1y ago
Here is one of the crash reports: https://crash-stats.mozilla.org/report/index/15999dc2-9465-4592-9ec5-b25e80250908 https://crash-stats.mozilla.org/report/index/15999dc2-9465-4... (I happened to have an un-subitted one which I just submitted, all the other ones I submitted are older than 6 months and have been purged.) It would crash in random spots, but usually some kind of X, GLX, EGL or similar library. But I don't think it was GLX, etc, because it also didn't save my profile except very very rarely, which was actually a much worse problem!! (This crash is from a long time ago, hence the old Firefox version.)
- capitainenemo 1y ago
  Is that proprietary nvidia driver stuff in the stack trace?
  - ars 1y ago
    Yes, without it YouTube plays at like 5fps. If it matters, that proprietary nvidia stuff is still there with the 64 bit which is rock solid. Also, I tried disabling EGL in the 32 bit with no effect on the crashing.
    - capitainenemo 1y ago
      hm. would be nice to have one of the traces with egl disabled. but I guess this is not really my problem to debug, esp since it's such an edge case (32 bit on 64 bit machine + nvidia blob) and given mozilla is abandoning support anyway.
- 1y ago