> Date: Fri, 2 Mar 2001 08:04:52 -0500 (EST)
> From: Peter Dufault <[EMAIL PROTECTED]>
> > Any strings "/B/u" in your program? That would be stored as 0x752f422f.
> >
> > If you're using assembly with using %ebp for stack frame (yay!), then make
> > certain %esp isn't getting corrupted.
(I meant _without_ %ebp, but I didn't want to repost.)
> Very good, I read those high bits off-by-one and stupidly didn't recognize
> the ascii:
>
> > (gdb) x/s $esp-8
> > 0x826b400 <dtablecount+6528>: "/wd0/B/usr-src/lib/libc_r/uthread/uthread_dup2.c"
> > (gdb)
>
> I guess it is the "thread_fd_lock_debug/_thread_fd_unlock_debug"
> calls with __FILE__ that push this on the stack. I'll build a
> debuggable libc_r and see I see.
Hmmmm. That "/B/u" portion is toward the beginning of the string, not the
end as one would expect from an overrun.
It looks like the string is getting written to -4(%esp,1), where %esp is
the initial stack pointer. Note that the return address is at 0(%esp,1).
What is the first variable that you declare in the function?
/* Note use of "&trashme" instead of "trashme" */
void foo (void) {
char *trashme;
strcpy((char*)&trashme, "/wd0/B/usr-src/libc/libc_r...");
}
If you compile using -fomit-frame-pointer, I _think_ that "trashme" would
be at -4(%esp,1). (Otherwise, %ebp would be saved at that address.)
It looks like you might be passing the address of a 32-bit variable to a
string function when you should be passing the contents. Anyone have any
other ideas off the top of their head?
Eddy
---------------------------------------------------------------------------
Brotsman & Dreger, Inc.
EverQuick Internet / EternalCommerce Division
E-Mail: [EMAIL PROTECTED]
Phone: (316) 794-8922
---------------------------------------------------------------------------
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
