Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Saturday August 07, 2004
05:10 AM

bblaunch segfault in Fedora Core 2

[ #20290 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

  • 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. ;-)

    • 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.
    • 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.

      • 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.