Interrupted system calls mitigated with tusc?

[Frank de Jong_1]

Hi,

I am trying to make an application (for HPUX 11i, or 11.11), where a third party executable 'A' dynamically loads a shared object (that I wrote) 'B', which in turn loads (with dlopen()) another third party's shared object 'C', and calls functions from it.

Now 'C' returns an error to me when call one of its functions (specifically, one that connects a socket to another machine).

When I write a small application that emulates what 'A' is supposed to be doing, it works, so 'A' is somehow fouling something up.

After some digging, I found out that somewhere in the call to 'C', an interrupted system call takes place (I am suspecting either in getsockname() or brk()).

Now my problem is that when I use 'tusc' to trace the system calls, everything works as it should, so somehow tusc seems to be mitigating the interrupted system call. Can anyone explain how this works?

Are there any open issues with the two functions I mentioned? Since 'C' is using libpthread, is there perhaps some other issue with pthreads that makes either function behave strangely?

Thanks in advance,

Frank

[Steven E. Protter]

Might want to post highlights of the tusc log.

All tusc should be doing is monitoring the process you hung it on. It should not be interfering with the operation of the application.

SEP

[Massimo Bianchi]

Hi,
first of all i'm totally ignorant in programming, but i followed some thread with similar problems.

Check the permission of the library, and be sure that they are r-xr-xr-x (no write).

Tusc maybe mitigating the error because it lead the program to run in a slightly different contest, like a debugger, and some shared library check are mitigated.

Massimo

[James Murtagh · Accepted solution]

Hi Frank,

The way a process responds to signals is different when it is being traced. When a signal is generated for the traced process, the kernel will suspend the process and will notify the parent via a sigchld signal, hence not invoking the default signal handler of the traced process. Hence in your case this is allowing the parent to intercept the signal and deal with it "correctly" in your case. Basically you need to look at the tusc output or code and see how the parents signal handlers are setup and code this for the child to avoid the interrupted syscall.

Cheers,

James.

[Frank de Jong_1]

Thanks for the replies.

Using tusc's -p and -l parameters, I found out that in the fragment in 'C' that was returning the error, the application 'A' is actually using a second LWP thread that sends the main thread a signal (SIGUSR2) using _lwp_kill. I am guessing this is some kind of keep-alive thread? I have written the coders of 'A' about it.

This explains why everything works when I use my emulating program (which does not have that second thread).

Regarding tusc, I think James' suggestion came closest to what I am experiencing - tusc is handling the signals differently than the application 'A' (since it effectively is the parent).

I've tried Massimo's suggestion, but it didn't help me.

For now, I'm going to wait a while for the coders of 'A' to respond, but thanks for the replies, folks!