debugging a seg fault

[Jeff]

I understand there's socket / recursive calls here, but this is a C
question, really it is:

Here's the code block in question:

#if defined(__GLIBC__)
{
struct hostent hent;
char hbf[8192];
memset(&hbf, '\0', 8192);
/* for systems using GNU libc */
if((gethostbyname_r(hostparam, &hent, hbf, sizeof(hbf), &hp,
&herrno) < 0)){
hp = NULL;
}
}
#elif defined(sun)

I'm passing Bad Things to gethostbyname_r and I'm trying to get to the
bottom of the problem. Here's my debugging session:

Breakpoint 1, new_socket (C=0xb7518b90, hostparam=0xb750efe4
"lsnas009.lsn.joedog.org", portparam=80) at sock.c:121
121 memset(&hbf, '\0', 8192);
(gdb) print hbf
$2 = '\0' <repeats 7976 times>, "ØÐN", '\0' <repeats 161 times>,
"Ta8", '\0' <repeats 13 times>, "üÆB\000¸:I\000u\2008\000]oH
\000\000\020\000\000¸:I\000TZ\000\000\000\000\000\ 000¸:I"
(gdb) print hent
$3 = {h_name = 0x19e0990 "&", h_aliases = 0x0, h_addrtype = 27133736,
h_length = 4135971, h_addr_list = 0x486f6a}
[Editor's note: WTF??? h_name is "&"]
(gdb) n

Lifting the server siege...123 if((gethostbyname_r(hostparam,
&hent, hbf, sizeof(hbf), &hp, &herrno) < 0)){
(gdb) n

Program received signal SIG32, Real-time event 32.
0x0042cfae in __open_nocancel () from /lib/tls/libc.so.6

I'm butchering something, somewhere and I'm having trouble getting to
the bottom of it. Any thoughts? How do I debug this?

Cheers,
Jeff

[Eric Sosman]

Jeff wrote:

I understand there's socket / recursive calls here, but this is a C
question, really it is:

Actually, it looks more like a gdb question. I'll offer a few
ideas anyhow, but realize that I'm not a gdb expert.

Here's the code block in question:

#if defined(__GLIBC__)
{
struct hostent hent;
char hbf[8192];
memset(&hbf, '\0', 8192);

Not really a problem, but this should be memset(hbf, '\0', 8192),
or better memset(hbf, '\0', sizeof hbf). Even better still would be
to find out whether you actually need to zero hbf[] before using it;
the clearing might be unnecessary.

/* for systems using GNU libc */
if((gethostbyname_r(hostparam, &hent, hbf, sizeof(hbf), &hp,
&herrno) < 0)){

This has more arguments than the gethostbyname_r() that I know,
but since gethostbyname_r() isn't a Standard C function there may
well be system-by-system variation. You didn't show what hp and
herrno are, but I'll just assume they make some kind of sense.

hp = NULL;
}
}
#elif defined(sun)

I'm passing Bad Things to gethostbyname_r and I'm trying to get to the
bottom of the problem. Here's my debugging session:

Breakpoint 1, new_socket (C=0xb7518b90, hostparam=0xb750efe4
"lsnas009.lsn.joedog.org", portparam=80) at sock.c:121
121 memset(&hbf, '\0', 8192);
(gdb) print hbf
$2 = '\0' <repeats 7976 times>, "ØÐN", '\0' <repeats 161 times>,
"Ta8", '\0' <repeats 13 times>, "üÆB\000¸:I\000u\2008\000]oH
\000\000\020\000\000¸:I\000TZ\000\000\000\000\000\ 000¸:I"

Here we get into gdb-specific territory. If I'm not mistaken,
the breakpoint stops the program *before* executing the line that's
printed out, so you're printing hbf *before* clearing it, and all
you're seeing is the garbage it contains at its creation.

(gdb) print hent
$3 = {h_name = 0x19e0990 "&", h_aliases = 0x0, h_addrtype = 27133736,
h_length = 4135971, h_addr_list = 0x486f6a}
[Editor's note: WTF??? h_name is "&"]

Similarly with hent: If you examine the contents of an object
that hasn't been initialized, so you can expect nothing sensible.

(gdb) n

Lifting the server siege...123 if((gethostbyname_r(hostparam,
&hent, hbf, sizeof(hbf), &hp, &herrno) < 0)){

I have no idea at all where that "Lifting the server siege..."
came from. Is this a multi-threaded program? If so, maybe one of
those other threads is running amok and trampling memory with heavy
mud-caked boots. (Multi-threading is not covered by the C language
standard, so the behavior of multi-threaded programs is another of
those things that varies from system to system.)

(gdb) n

Program received signal SIG32, Real-time event 32.
0x0042cfae in __open_nocancel () from /lib/tls/libc.so.6

I'm butchering something, somewhere and I'm having trouble getting to
the bottom of it. Any thoughts? How do I debug this?

First, check that the calls to system-specific routines like
gethostbyname_r() are in fact written correctly: Making sure that
all the appropriate header files have been #include'd is a good start.
Second, check that you're using gdb correctly; if you need help on
that, a Gnu forum is the place to seek it. Third, Gnu forums are
also likely to be the best sources of information about glibc details;
comp.unix.programmer is another place to get advice on Unix networking
API's. Finally, try comp.programming.threads if you need ideas about
debugging multi-threaded programs.

... and if you ever *do* have a C question, please come back
here for advice, help, and unending flames.

--
Er*********@sun.com

[Keith Thompson]

David Resnick <ln********@gmail.comwrites:
[...]

If your questions have to do with threading/gethostbyname_r
themselves, you're better off asking in comp.programmer.unix.

[...]

Or comp.unix.programmer, which has the virtue of actually existing.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Jeff wrote:

>
I understand there's socket / recursive calls here, but this is
a C question, really it is:

Here's the code block in question:

#if defined(__GLIBC__)
{

To start with, you are using a reserved identifier. All
identifiers with two leading '_' chars are reserved for the
implementation.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Jens Thoms Toerring]

CBFalconer <cb********@yahoo.comwrote:

Jeff wrote:

I understand there's socket / recursive calls here, but this is
a C question, really it is:

Here's the code block in question:

#if defined(__GLIBC__)
{

To start with, you are using a reserved identifier. All
identifiers with two leading '_' chars are reserved for the
implementation.

He's testing something ("__GLIBC__") that might be defined by the
implementation, so what's the worry? It's not the OP defining it.

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[Jeff]

On Jul 24, 4:18 pm, Eric Sosman <[e-mail]:

Jeff wrote:

I understand there's socket / recursive calls here, but this is a C
question, really it is:

Actually, it looks more like a gdb question. I'll offer a few
ideas anyhow, but realize that I'm not a gdb expert.

Thanks. I thought I was looking at it *after* initialization. Electric
Fence offered no additional insight. I'll try David's suggestion and
use valgrind. I'm reasonably certain I'm clobbering something prior to
the gethostbyname_r call. This code fails only in conjunction with a
new authentication mechanism I added.

Jeff

[Richard]

Jeff <jo******@gmail.comwrites:

On Jul 24, 4:18 pm, Eric Sosman <[e-mail]:

>Jeff wrote:

I understand there's socket / recursive calls here, but this is a C
question, really it is:

Actually, it looks more like a gdb question. I'll offer a few
ideas anyhow, but realize that I'm not a gdb expert.

Thanks. I thought I was looking at it *after* initialization. Electric
Fence offered no additional insight. I'll try David's suggestion and
use valgrind. I'm reasonably certain I'm clobbering something prior to
the gethostbyname_r call. This code fails only in conjunction with a
new authentication mechanism I added.

Jeff

Be aware you can use gdb to set read and write break points too.

http://www.unknownroad.com/rtfm/gdbtut/gdbwatch.html