Problem in vsprintf in a Multithereaded environment

[sikky_deep]

Hi Friends,

I was developing a function for making entries to log files in c++
My function looks like this:

void makeLog(int  log_level,char *arg,...)
{
    char            temp_str[512]={0,};
    va_list         ap;
    va_start(ap,arg);
    vsprintf(temp_str,arg,ap);
    ..
    ..
}

this function works well most of the time, but some time it generates a core dump at line
vsprintf(temp_str,arg,ap);
The string i am sending is also not longer than 512 bytes.
Im using multiple threds , which calls this makeLog function.
can any body give me a solution how can i overcome this problem
waiting for your responses.
Thanks and Regards
Pardeep

[Salem]

> The string i am sending is also not longer than 512 bytes.
But what about it's length after formatting?

Try something like

char temp_str[10000];
vsprintf(temp_str,arg,ap);
if ( strlen(temp_str) >= 512 ) {
  fprintf(stderr, "I was wrong\n" );
}

> Im using multiple threds , which calls this makeLog function.
If you linked with a multi-thread library, that shouldn't be a problem

When you say 'core dump', are you referring to the Linux/Unix core dump?
Because then you can load the core file into gdb and use the 'bt' command to give you a stack trace of where it stopped.

If that stack trace shows that vsprintf() was in turn calling malloc/free, then you have a much bigger problem to solve. You've trashed the memory pool and this is merely the symptom of the problem, not the cause of the problem.

[sikky_deep]

> The string i am sending is also not longer than 512 bytes.
But what about it's length after formatting?

Try something like

char temp_str[10000];
vsprintf(temp_str,arg,ap);
if ( strlen(temp_str) >= 512 ) {
  fprintf(stderr, "I was wrong\n" );
}

> Im using multiple threds , which calls this makeLog function.
If you linked with a multi-thread library, that shouldn't be a problem

When you say 'core dump', are you referring to the Linux/Unix core dump?
Because then you can load the core file into gdb and use the 'bt' command to give you a stack trace of where it stopped.

If that stack trace shows that vsprintf() was in turn calling malloc/free, then you have a much bigger problem to solve. You've trashed the memory pool and this is merely the symptom of the problem, not the cause of the problem.

------------------------------

Yes u r right, i m using the g++ compiler in the Linux environment, and when i see the core file by using the bt option in the gdb, it stats that vsprintf is the last funtion call at which program terminated abnormally,
and also the string even after formatting is less than 200 characters in any case.
thats why i thought it might havr brrn caused by multiple threads running and calling this function.
u have talked about calls to malloc/free in vsprintf. i did'nt understood that point, coz i cant see any other funtion call in the core file.
could u please guide me of what are the options i can go for.

Thanks and Regards
pardeep

[Salem]

Perhaps post your 'bt' trace?

[sikky_deep]

Perhaps post your 'bt' trace?

sorry for replying late, that problem didnt came for some days, but now it is again coming at strlen(), and following is the Backtrace for it:

Core was generated by `'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from
/home/oracle/product/10.2.0/lib/libclntsh.so.10.1...done.
Loaded symbols for /home/oracle/product/10.2.0/lib/libclntsh.so.10.1
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/lib/libstdc++.so.5
Reading symbols from /lib/tls/libm.so.6...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from
/home/oracle/product/10.2.0/lib/libnnz10.so...done.
Loaded symbols for /home/oracle/product/10.2.0/lib/libnnz10.so
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0 0x008ca41b in strlen () from /lib/tls/libc.so.6

(gdb) bt

#0 0x008ca41b in strlen () from /lib/tls/libc.so.6
#1 0x00898581 in vfprintf () from /lib/tls/libc.so.6
#2 0x008b43dc in vsprintf () from /lib/tls/libc.so.6
#3 0x08056470 in CSpMain::makeLog (this=0x8070200, log_level=2,
arg=0x806687c "SendReplaceMessage :: Sequenece number[%ld]
SubscriberNo[%s] MsgSeq[%s]")
at /prd/SRC/SCInterface/sp_main.cpp:2509
#4 0x08053ecc in CSpMain::SendReplaceMessage (this=0x32332030,
DataBlock_st=0x20653220)
at /prd/SRC/SCInterface/sp_main.cpp:1608
#5 0x33206133 in ?? ()
#6 0x32332030 in ?? ()
#7 0x20653220 in ?? ()
#8 0x08066400 in MAXRECV ()
#9 0x00000004 in ?? ()
Previous frame inner to this frame (corrupt stack?)

[Salem]

> #3 0x08056470 in CSpMain::makeLog (this=0x8070200, log_level=2,
> arg=0x806687c "SendReplaceMessage :: Sequenece number[%ld]
> SubscriberNo[%s] MsgSeq[%s]")
From the look of it, I would say that one of the two string parameters you expected to format with those %s conversions is bad in some way.
The first check is are the correct number/type of parameters being passed.

Does it always fail at this point in the code (is it repeatable)?
If so, you should be able to put a counting breakpoint on your logging function and trap at the call which will fail.

Check the first call to your logging function to make sure the 'bt' isn't full of all those ?? entries.

> #4 0x08053ecc in CSpMain:endReplaceMessage (this=0x32332030,
> DataBlock_st=0x20653220)
As strings, 0x32332030 = "23 0" and 0x20653220=" e2 "
Do these look like any data you could have read?
Because when I see addresses which are all printable characters, then it's a pretty solid bet that some memory corruption is going on.

> Previous frame inner to this frame (corrupt stack?)
If this really is the case, then it's not a good sign. Check all your local arrays (particularly char arrays) for overflow. Since this is C++, consider a process of migrating C strings to C++ std::string as you work on modules.

Another possibility is that you compiled some of the code with "-fomit-frame-pointer"

`-fomit-frame-pointer'
Don't keep the frame pointer in a register for functions that
don't need one. This avoids the instructions to save, set up and
restore frame pointers; it also makes an extra register available
in many functions. *It also makes debugging impossible on some
machines.*

[sikky_deep]

yes i think that the data coming into the string is in some way corrupted,
i will look into the root to find whats wrong there.
Thanks a lot for the Advice.