vsprintf causing segmentation fault

knobby67 · 01-08-2011, 07:49 AM

Hi all,
I'm working on some code which suddenly is causing a segmentation on vsprintf. This was working before, so I cut and pasted some code from vsprintf function at the cplusplus site and even this is causing a problem. Anyway the example is

Code:

void PrintFError (const char * format, ...)
{
  char buffer[256];
  va_list args;
  va_start (args, format);
  vsprintf (buffer,format, args);
  perror (buffer);
  va_end (args);
}

and I call PrintFError ("hello world"); This gives

Program received signal SIGSEGV, Segmentation fault.
0xb73e283d in ?? ()

and gdb shows a segmentation crash on vsprintf. The g++ version is
g++ --version

g++ (Debian 4.3.2-1.1) 4.3.2

Can anyone advise?

Sergei Steshenko · 01-08-2011, 08:13 AM

Quote:

Originally Posted by knobby67

... Can anyone advise?

Sure - start debugging. Either by inserting diagnostic prints or by using 'gdb'. For the latter perform WEB search on

gdb segmentation fault tutorial

- for example, first match from Yahoo.
...
Does your compilation command line have '-Wall -Wextra' ? If doesn't, add the items and first make sure there are no warnings.

ntubski · 01-08-2011, 09:45 AM

What you posted works for me:

Code:

~/tmp$ cat vperror.c
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>

void PrintFError (const char * format, ...)
{
  char buffer[256];
  va_list args;
  va_start (args, format);
  vsprintf (buffer,format, args);
  perror (buffer);
  va_end (args);
}

int main()
{
    PrintFError("hello world");
    return 0;
}
~/tmp$ make vperror
gcc -Wall -Wextra -ansi -pedantic    vperror.c   -o vperror
~/tmp$ ./vperror
hello world: Success
~/tmp$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

knobby67 · 01-08-2011, 10:47 AM

I have ran through gdb and valgrind which shows

==7566== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 65 from 1)
==7566== malloc/free: in use at exit: 0 bytes in 0 blocks.
==7566== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==7566== For counts of detected errors, rerun with: -v
==7566== All heap blocks were freed -- no leaks are possible.

also it runs on another PC running Ubuntu, so I'm assuming that on my Debian laptop it's either the hardware or a deb./gcc version fault

johnsfine · 01-08-2011, 10:55 AM

Quote:

Originally Posted by knobby67

it runs on another PC running Ubuntu, so I'm assuming that on my Debian laptop it's either the hardware or a deb./gcc version fault

A hardware fault is extremely unlikely based on the info you have posted in this thread. A library version incompatibility is fairly unlikely, but should be considered.

If a program runs without symptoms, that never proves the program is correct. If the same program fails on a different computer, that doesn't indicate anything is wrong with the computer where the failure occurred. Bugs in programs often hide (run with no symptoms). A bug may be revealed by a change that has no direct relationship to the bug.

So far you haven't really told us what you're actually doing.

Did you duplicate the malfunction with a tiny program similar to the one ntubski posted? Or is the failure only occurring inside a more complicated program (too big for you to post the whole thing)?

Quote:

Originally Posted by knobby67

gdb shows a segmentation crash on vsprintf.?

Quote:

Originally Posted by Sergei Steshenko

start debugging. Either by inserting diagnostic prints or by using 'gdb'.

If I were debugging this, I could make direct progress from the point that gdb shows a seg fault in vsprintf. But I would do that by looking at the cpu registers and stack and disassembly of the code at the point of failure. For someone who doesn't know x86 assembler, there may be no clean way forward using gdb. IIUC, the failure is seen in a library routine and there is nothing obviously wrong at the source level with the parameters passed to that library routine. That is a very hard situation to diagnose if you don't know assembler.

When I suspect a library version incompatibility, I use the ldd command on the executable and look at the results to see if anything looks suspicious. You might want to post the results of ldd, because I can't really tell you what to interpret as "suspicious" by yourself, but maybe some expert here seeing your ldd output would spot a possible problem.

If you know gdb commands but not x86 assembler, you could post the registers, stack and disassembly at the point of failure. I might make a good guess at the problem based on just those.

Sergei Steshenko · 01-08-2011, 11:11 AM

Quote:

Originally Posted by johnsfine

...
If I were debugging this, I could make direct progress from the point that gdb shows a seg fault in vsprintf. But I would do that by looking at the cpu registers and stack and disassembly of the code at the point of failure. For someone who doesn't know x86 assembler, there may be no clean way forward using gdb. ...

'glibc' source is readily available. 'vsprintf' source can be, for example, copy-pasted into the program to be debugged, so debugging at "C" (rather than assembly) level will become possible.

But maybe the problem is not that deep, i.e. maybe some of the arguments/variable are corrupted - this can be seen with 'gdb' ot diagnostic prints.