Program dies when run with LD_AUDIT set
I am using SunStudio 11 with the recommended OS and compiler patches. I have been using the check -access feature in dbx on my machine running Solaris 8 just fine. I have installed SunStudio 11 on another machine with Solaris 10 again with the recommened OS and compiler patches. Now my program crashes in a call to sigaction (have not attached with dbx yet). If I run it without LD_AUDIT set, it runs fine. I did a sum on rtcaudit.so and got the same value for it on Solaris 8 machine where all is fine and Solaris 10 where it crashes.All the code was compiled on each machine.I took the program compiled on Solaris 8 and ran it with LD_AUDIT set on the Solaris 10 machine and it runs fine. so it seems, so far, my program compiled on Solaris 10 and run with LD_AUDIT set crashes. Runs fine if LD_AUDIT not set and/or the program was compiled on Solaris 8.
Any ideas?
[881 byte] By [
peccles] at [2007-11-26 9:37:49]
# 1
First of all, you can (if you want to) file a problem report with bugs.sun.com
for the Sun Studio tools. But I will assume you are also willing to investigate
more on your own.
So let me rephrase what you said. You have two different programs. One works
on S10 with LD_AUDIT, and one fails. So you need to find out what's
different between those two programs. (One was created on S8 one on S10).
Often, problems with RTC are related to dynamic library orders. Try building
all your .o files on S10, and changing only the link step. Link one program
on S8 and one on S10. I expect you to have the same problem, but it's good
to check.
Then you can use the 'ldd' utility on both programs on S10. That will show
the list of shared libraries that will be loaded, and the ordering. If that
list of libraries is different (due to linking on S8 and S10) you can try to
reproduce the S8 library order using -l options when linking on S10.
Actually, I forgot the most important thing..... Now I feel dumb.
Can you post the stack trace of the crash?
--chris
# 2
There's a bug in runtime linker (man ld.so.1), which reproduces only when there's auditing library and some or all libraries are marked as lazy-loadable. If you set LD_NOLAZYLOAD to some non-null value, the problem I've mentioned should go away. This way you can at least make sure which problem you're facing.
