I am using a closed-source 3rd party Linux lib (.so) compiled for an older version of Linux on an older version of gcc.
Unfortunately, it crashes occasionally with a read of an invalid memory address.
This is certainly undesirable, and it would be fantastic to fix the library. But as that is absolutely impossible, and it still functions perfectly well on older versions of Linux, is there some way to avoid the crash, and simply restart the app every day?
It’s either that or attempt to run it on an extremely old version of Linux that apparently ignores such errors.
Update 2020-07-09
Everything is working reliably now, see my answer below. Sometimes the act of posing a question in a succinct way leads to finding the correct answer.
Advertisement
Answer
I am using a closed-source 3rd party Linux lib (.so) compiled for an older version of Linux on an older version of gcc.
Note that neither “older Linux” nor “older gcc” is the reason for the crash, a bug in the library is. A bug-less library compiled 15 years ago would still work perfectly fine today.
it would be fantastic to fix the library. But as that is absolutely impossible, and it still functions perfectly well on older versions of Linux, is there some way to avoid the crash, and simply restart the app every day?
In general, you can’t “avoid the crash and continue as if nothing happened”. But you can attempt to “catch the crash, save state and restart the application” with a SIGSEGV signal handler which executes siglongjmp.
This will be more or less reliable depending on the exact reason for the crash (which you haven’t described).
It’s either that or attempt to run it on an extremely old version of Linux that apparently ignores such errors.
Old Linux did not ignore such problems: invalid memory access has always generated a crash.
But old Linux (probably) didn’t violate the 3rd party developer’s incorrect assumptions, and new one does, triggering the invalid memory access.
You should try to understand what causes the crash (which assumptions are violated). There might be a trivial workaround.
E.g. if the library assumed a process can’t have more than 1024 file descriptors, and used select, you can arrange that the library never observes fd >= 1024, by reserving “low” file descriptors for it.