linux strace shows read(13, <unfinished ...> as last strace when program throws segmentation fault.

In Linux, I did  strace for my program (multi-thread processing) when I stop the process. the last strace statement is below. what does it mean "read(13, <unfinished ...>?
Does it mean the program try to read something from file descriptor 13, and not finish and then get segmentation fault?
or the program read something invalid?

write(5, "{NULL, 7, 1, SM_ProcMgmt.C, 74, "..., 87) = 87
write(12, "\0\0\0\0", 4)                = 4
read(13,  <unfinished ...>

I did a gdb for the core file, and see segmentation fault as below. I check the line 1513, is return(NULL) from a function which return void* ( void*SM_ProcMgmt::signalThread(void* arg)).
So return (null) should be valid. Any idea would be appreciated on how to further debug and what could be wrong?

# 0  0x00000000 in ?? ()
#1  0xf7df05df in SM_ProcMgmt::signalThread (arg=0xffc21f30) at SM_ProcMgmt.C:1513
#2  0x00c1f832 in start_thread () from /lib/libpthread.so.0
#3  0x00b89f6e in clone () from /lib/libc.so.6



+++ killed by SIGSEGV (core dumped) +++
ndoungAsked:
Who is Participating?
 
Duncan RoeSoftware DeveloperCommented:
Yes there is an unfinished read() on file unit 13. However it is not even likely that this is the cause of the SIGSEGV (unless, for instance, the buffer address is out of range).
You need to look back up your strace output until you find what is open on file unit 13. If, say, it's a pipe (as distinct from a regular file) then incomplete read is perfectly normal until something writes to the other end of the pipe.
From the stack trace it more looks like clone() has been given a bad argument. But the clone() call is not in the strace output - did you use strace -f? You need to do that with multithreaded programs to see threads other than the first.
If you gdb the program, you can examine variables at the time of the SIGSEGV
0
 
ndoungAuthor Commented:
I've requested that this question be deleted for the following reason:

I no longer need to resolve the problem. So I do not need to pursuit.
0
 
Duncan RoeSoftware DeveloperCommented:
Just because ndoung no longer wishes to pursue this problem is no reason to delete valid answers andrefund his points. I think my initial answer was valid as far as it went - I expected the asker to pursue it further but he has chosen not to
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.