18 Jan
2003
18 Jan
'03
5:15 p.m.
I'm testing the code I've written to spamproof the ClassicCmp web site and
archives. I call the system SpamCamo. The file filter works great and
produces links as it should. The CGI program is not behaving and is giving
me some *very* wierd behavior. I'm stumped.
First, if I compile with this:
$ cc -o spamcamo.cgi cgi.c spamcamo.cgi.c -lcipher
I get a "Bus error (core dumped)" exception from the first statement in my
program, which is printf("DEBUG: 0\n"). I have used gdb to verify this, and
it tells me that SIGBUS is occuring inside isatty() in libc.
Now, if I compile like this, switching the order of the source files but
making NO changes to the source files themselves:
$ cc -o spamcamo.cgi spamcamo.cgi.c cgi.c -lcipher
The program proceeds to the first call of strdup(), which returns NULL and
sets errno to EINVAL. strdup() is definitely receiving a valid string.
Furthermore, malloc(1) (as in "allocate one byte") in the same place also
fails with EINVAL. The machine is not low on memory. Even furthermore, the
code that is failing in this case (in cgi.c) works correctly when compiled
against a test program (proof: http://www.subatomix.com/test_cgi.cgi?a=b)
instead of spamcamo.cgi.c. This is what the program does (i.e. not much)
before calling strdup():
printf()
function call
function call
getenv()
return
strcmp()
funcion call
getenv()
return
strdup() <--- SIGBUS occurs here
I get the same results on two FreeBSD boxen. One is running 4.5-RELEASE and
the other is running 4.6-STABLE. I'd like to think this is something I've
done wrong and not a bug in libc. Any ideas?
--
Jeffrey Sharp
18 Jan
18 Jan
7:02 p.m.
BTW, the code in question can be seen at:
http://www.subatomix.com/etc/spamcamo/
On Sunday, January 19, 2003, Jeffrey Sharp wrote:
I'm testing the code I've written to spamproof
the ClassicCmp web site and
archives. I call the system SpamCamo. The file filter works great and
produces links as it should. The CGI program is not behaving and is giving
me some *very* wierd behavior. I'm stumped.
First, if I compile with this:
$ cc -o spamcamo.cgi cgi.c spamcamo.cgi.c -lcipher
I get a "Bus error (core dumped)" exception from the first statement in my
program, which is printf("DEBUG: 0\n"). I have used gdb to verify this,
and it tells me that SIGBUS is occuring inside isatty() in libc.
Now, if I compile like this, switching the order of the source files but
making NO changes to the source files themselves:
$ cc -o spamcamo.cgi spamcamo.cgi.c cgi.c -lcipher
The program proceeds to the first call of strdup(), which returns NULL and
sets errno to EINVAL. strdup() is definitely receiving a valid string.
Furthermore, malloc(1) (as in "allocate one byte") in the same place also
fails with EINVAL. The machine is not low on memory. Even furthermore, the
code that is failing in this case (in cgi.c) works correctly when compiled
against a test program (proof: http://www.subatomix.com/test_cgi.cgi?a=b)
instead of spamcamo.cgi.c. This is what the program does (i.e. not much)
before calling strdup():
printf()
function call
function call
getenv()
return
strcmp()
funcion call
getenv()
return
strdup() <--- SIGBUS occurs here
I get the same results on two FreeBSD boxen. One is running 4.5-RELEASE and
the other is running 4.6-STABLE. I'd like to think this is something I've
done wrong and not a bug in libc. Any ideas?
--
Jeffrey Sharp
7:35 p.m.
Ladies and gentleman, we have a winner. Thanks, Kevin!
Kevin Schoedel wrote (privately):
OK, having now seen the code, I suspect the problem is
that you have a
function called end(). 'end' has traditionally been used by Unix systems
for the address of the end of program memory. (I'm not sure where you'll
find this documented -- maybe under ld(1).) This would explain the
different results when you compile (and link) in a different order --
different memory is corrupted depending on where your end() appears.
--
Jeffrey Sharp
7:03 p.m.
It was thus said that the Great Jeffrey Sharp once stated:
I'm testing the code I've written to spamproof the ClassicCmp web site and
archives. I call the system SpamCamo. The file filter works great and
produces links as it should. The CGI program is not behaving and is giving
me some *very* wierd behavior. I'm stumped.
I get the same results on two FreeBSD boxen. One is running 4.5-RELEASE and
the other is running 4.6-STABLE. I'd like to think this is something I've
done wrong and not a bug in libc. Any ideas?
Hard to say without seeing the code. I do have a library I wrote (in C,
GPLed) that handles CGI requests that has an *extensive* debugging facility
built in you could use (I can even supply sample CGI programs) that I've
used on multiple Unix platforms (IRIX, Linux (Intel and DEC Alpha---actually
found a libc bug on the DEC Alpha with my code), OpenBSD---not sure about
FreeBSD but it should compile fine).
Conversely if you want, I can take a look at the code and possibly figure
out what's wrong (I do have access to Linux on Intel and DEC Alpha, OpenBSD
and Solaris 8x (and maybe HP-UX 10.20 in a day or two)). That might
actually isolate the problem to FreeBSD (or your code).
-spc (Have C compiler, will code)
19 Jan
19 Jan
12:12 a.m.
On Sun, 19 Jan 2003, Jeffrey Sharp wrote:
I get the same results on two FreeBSD boxen. One is
running 4.5-RELEASE
and the other is running 4.6-STABLE. I'd like to think this is something
I've done wrong and not a bug in libc. Any ideas?
I would have to speculate that it's definitely something specific to your
box. Perhaps you have a bad install of gcc? Perhaps there's something
wierd in spamcamo.cgi? In either compile case, this file comes first.
Maybe it's affecting the subsequent compiles?
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
8012
days inactive
8012
days old
4 comments
3 participants
participants (3)
-
foo＠siconic.com -
jss＠subatomix.com -
spc＠conman.org