[comp.lang.c] C Programs and sdb

pjh@mccc.UUCP (Peter J. Holsberg) (12/01/87)

I wrote and compiled a large program and when it executes, I get a core
dump.  (SysVr3 on a 3B2/400)  When I try to use sdb, it refers me to a
nonexistent 'strncmp.c' file, and says:

	0x80802d0b in strncpy:No lines in file
	*Memory Fault (11) (sig 11)
 	  at
	0x80802d0b in strncpy:No lines in file

strncpy() is used many many times in the program, and is used
correctly, and with the proper header file.

What could be wrong???

-- 
Peter Holsberg				UUCP: {rutgers!}princeton!mccc!pjh
Technology Division			CompuServe: 70240,334
Mercer College				GEnie: PJHOLSBERG
Trenton, NJ 08690			Voice: 1-609-586-4800

peter@thirdi.UUCP (Peter Rowell) (12/02/87)

I suspect (but have no 3b2 to verify on) that one or more of the files
that make up your /lib/libc.a (which contains all of the standard C
library routines) were compiled with the "-g" switch.  When sdb sees
this extra info, it wants to find the named file and display it.

It would seem that there is a bug in sdb (probably not the first you
have seen, and certainly not the last you will see) where they are not
catching that the file is not viewable.  You could test for this by
creating a file called "strncmp.c" with a bunch of random lines in it
(at least as many as the original source file had) and then fire sdb up
again and see what it does.  If it stops blowing up, that's the problem.

Fixing it will require removing "local symbols" from the library
without completely stripping it.  This can be done by doing the
following:

#-------------------------
mkdir /tmp/newlib
cd /tmp/newlib
# get list of .o order in libc
ar -t /lib/libc.a > list
# extract the .o's
ar -x /lib/libc.a
# now we loop through and clean up unwanted symbols
for $file in `cat list`
    ld -x -r $file
    mv a.out $file
done
# finally we rebuild the library
ar -qv libc.a `cat list`
# and put it somewhere safe
mv libc.a /your/home/dir/or/what/ever
#-------------------------

Now you can reload using your new library and see if the problem goes
away.  If it does, save your current /lib/libc.a somewhere and replace
it with your new libc.a.

There is one CAVEAT here: not all implementations of "ld" under
System V implement (or implement correctly) the "-x" switch.  Your
version may do nothing, core dump, or do the correct thing....

Good Luck,
    Peter Rowell
    (415) 321-0967

carroll@snail.CS.UIUC.EDU (12/04/87)

	I means that the library function "strncmp" had a core dump, and
sdb is looking for source to it. Obviously, there isn't any. What you should
do is use the "t" command to trace back on the stack, and see what values
you passed strncmp. It doesn't do any checking about the pointer values
it gets (because that would be a real nightmare to implement, if not
outright impossible). If you pass strncmp a bogus pointer, it will go ahead
and try to use it, and then core dump, giving the effect you seem to have.

manes@dasys1.UUCP (12/04/87)

In article <161@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes:
>
>I wrote and compiled a large program and when it executes, I get a core
>dump.  (SysVr3 on a 3B2/400)  When I try to use sdb, it refers me to a
>nonexistent 'strncmp.c' file, and says:
>
>	0x80802d0b in strncpy:No lines in file
>	*Memory Fault (11) (sig 11)
> 	  at
>	0x80802d0b in strncpy:No lines in file
>
>What could be wrong???

Don't forget that C libraries also reference themselves and that a core
dump on something like 'strncpy' or 'strcmp' may not be one that you put in
your source file but called from something like printf().  The only thing
you can really do is single-step through your code until the program dumps
and see what library function caused the problem (after acertaining that
your code is beyond criticism :^)  Then check your arguments VERY closely
and make sure that the function is getting all the arguments that it
expects and of the proper type.  Since you're getting a segmentation
violation (sig 11) also check to make sure that you're linking withthe
correct model (the linker SHOULD catch this).

This wouldn't be Microport V/386 you're using, would it?


-- 
+-----------------------------------------------------------------------
+ Steve Manes         Roxy Recorders, Inc.                 NYC
+ decvax!philabs!cmcl2!hombre!magpie!manes       Magpie BBS: 212-420-0527
+ uunet!iuvax!bsu-cs!zoo-hq!magpie!manes              300/1200/2400

lvc@tut.UUCP (12/04/87)

In article <271@thirdi.UUCP>, peter@thirdi.UUCP (Peter Rowell) writes:
> I suspect (but have no 3b2 to verify on) that one or more of the files
> that make up your /lib/libc.a (which contains all of the standard C
> library routines) were compiled with the "-g" switch.  When sdb sees
> this extra info, it wants to find the named file and display it.
> 
	...

Good guess, but actually, the 3b2 3b5 and 3b15 compilers insert this
assembly language instruction:

	.file "filename"

at the beginning of the .s file when you compile a file (with or without
the -g option).  This is where sdb is getting the file names.
The assembler stores this and some other stuff in the a.out header.

Which reminds me of a gripe I have with the 3b compilers, they also insert
the time the program was compiled into the a.out header.  I have to have a
special program to compare two a.out files to see if they are the same!

-- 
	Larry Cipriani AT&T Network Systems at
	cbosgd!osu-cis!tut!lvc Ohio State University

randy@umn-cs.UUCP (12/05/87)

In article <2143@dasys1.UUCP> manes@dasys1.UUCP (Steve Manes) writes:
>In article <161@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes:
  [about a program that dumps core in a non-existant file strncpy.c]
>>
>>What could be wrong???
>
>Don't forget that C libraries also reference themselves and that a core
>dump on something like 'strncpy' or 'strcmp' may not be one that you put in
>your source file but called from something like printf().


I haven't yet seen anyone mention the obvious solution:  There's a call to
the library strncpy routine in his program, and he's passing it a NULL (or
other invalid pointer).

Here's a question:  why don't they put absolute path names in library
modules?  It wouldn't be any worse than the current situation, and in
many cases (sites with source liscense, who use it) it would be reall
handy.

	-randy
-- 
Randy Orrison, University of Minnesota School of Mathematics  | May the smiley
UUCP:	{ihnp4, seismo!rutgers, sun}!umn-cs!randy	      |      O__\,
ARPA:	randy@ux.acss.umn.edu		BITNET: randy@umnacca |      O  /'
Disclaimer:  No one is silly enough to pay me to do this.     |  be with you!