bblaunch segfault in Fedora Core 2

Ovid on 2004-08-07T10:10:14

Posted primarily as a google lookup.

Once again I need to brush up on my C. In order to get borderless terminals with aterm and fluxbox working, I had to use bblaunch. As it turns out, bblaunch, an unmaintained program that both blackbox and fluxbox use, has the following line of code in it:

sprintf(launchargs.call, "%s", (char *)atoi(argv[0]));

With launchargs being a struct:

typedef struct LArgs
  { 
    char call[1024];
    char command[1024];
    unsigned long flags, attrib, workspace, stack, decoration;
    unsigned long pause;
    Bool iconic;
  } LArgs;

While that line works fine in Redhat 8, it segfaults under Fedora Core 2. As it turns out, launchargs.call is not actually used, so I was able to comment out that line in bblaunch and recompile and everything worked fine. Now I need to dig in to find out the reason for the segfault. If only I knew C as well as Perl.

---

chasing segfaults

nicholas on 2004-08-07T10:48:17

Now I need to dig in to find out the reason for the segfault. If only I knew C as well as Perl.

If you've not got a coredump already from it, I'd suggest running it under gdb and using that to see where it goes boom. All the code looks legal, and I can't see anything that can actually go wrong. Except that argv[0] might be a null pointer. Which seems unlikely, but is the only possible problem that I can spot.

Strange construct

VSarkiss on 2004-08-07T11:52:30

Unless something weird is going on, argv[0] should be the program name. So doing an atoi will generally produce nothing useful, unless the program's name is 666 or some such.

That said, it seems a far simpler way to do what the code's doing is to just use sprintf to do the work:

sprintf(launchargs.call, "%d", argv[0]);

Which would do nothing -- including not segfault -- if argv[0] isn't numeric.

Fair warning: it's 4:30 am as I write this, after a bout of insomnia. Use at your own risk. ;-)

Re:Strange construct

rooneg on 2004-08-07T14:59:34

Worse yet, calling atoi on it will give you back an integer, which is then being cast to a char *, so you're looking in whatever bit of memory the integer value you get refers to and treating it as a character array. There's nothing good that can come of this, it's quite broken.

Re:Strange construct

nicholas on 2004-08-07T21:48:58

Oh yes, crap. I missed that cast.

Re:Strange construct

nicholas on 2004-08-07T21:51:28

Unless something weird is going on, argv[0] should be the program name.

True. There's insufficient context to see whether anyone modified argv (++argv or somesuch). I'm not sure if I'd count modifying argv as weird though, as I've been known to write code that increments it in a while loop to process all command line arguments.

Re:Strange construct

VSarkiss on 2004-08-07T22:11:41

I meant unless argv isn't even the command line: if it's an array internal to the program or something. Nothing in C enforces using argc and argv for program arguments; it's just a convention that is all too often broken.