3 ms·

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

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.

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.