We are facing a sever issue in our application after our customer updated the Solaris 10 kernel patch u9 to u10.
We have two static libraries libdlib.a and libDLIB.a, with exactly same code base, but these two libraries are scattered across the code base and linked by many shared objects in our application.
However, one of the shared objects that links to "libdlib.a" library tries to access a function from "libDLIB.a". This behavior is causing a crash at a later point, since that shared object is supposed to access the function from "libdlib.a". Moreover, we found this is happening through the use of dbx.
I'm unable to understand why this problem surfaced after kernel patch update, though still the shared object works fine on Solaris 10 u9 patch.
Flow is something like this :
1. syslogrecorder.so gets loaded by one of the processes.
2. syslogrecorder.so is linked to "libdlib.a" at compile time, so it uses "libdlib.a" function DLIB_LoadLibrary and gets a handle to all the function pointers of the loaded library ( The purpose of DLIB_LoadLibrary is to load a shared library dynamically using dlopen )
3. syslogrecorder.so tries to do a "dlsym" and to do that it needs access to the library handle which we got in previous call DLIB_LoadLibrary. So syslogrecorder.so calls another function from DLIB_ProcAddress, which actually gives back the access to the loaded shared library.
Here is a catch in step 3, it is supposed to call DLIB_ProcAddress from the libdlib.a but as we observed from dbx output it does so by calling DLIB_ProcAddress from libDLIB.a and hence fails to give back the access to loaded shared library, causing crash at a later point in code.
Can someone put some light here that why this could happen ??
To clarify: You did not modify or rebuild any of your binaries, but after installing a kernel patch, the application stopped working. Most likely, something about your application depended on a accidental behavior of the runtime loader. That accidental behavior changed due to the patch, and your application failed.
For example, if there is a circular dependency among shared libraries, the loader will break the cycle at an arbitrary point to establish an initialization order. By accident, that order might work, in the sense of not causing a problem. A change to the loader could cause the cycle to be broken at a different point, and the resulting initialization order could cause a now-uninitialized object to be accessed. I'm not saying this is what is wrong, but this is an example of a dependency on accidental loader behavior.
Finding your actual problem will require tracing the sequence of operations leading up to the failure. You are more likely to find help in a Solaris linker forum. AFAIK, there are currently no Oracle forums for Solaris, and the old OpenSolaris forums have been converted to mailing lists. You can try the "tools-linking" list found on this page:
I also suggest you review the paper on best practices for using shared libraries written by Darryl Gove and myself:
If you have a service contract with Oracle, you can use your support channel to get more help.