Date: Fri, 13 Jun 1997 14:59:36 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jin@george.lbl.gov (Jin Guojun[ITG]) Cc: smp@csn.net, bugs@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: (kern/3827) : was ASUS P/I-P65UP5 with C-P55T2D Message-ID: <199706132159.OAA11667@phaeton.artisoft.com> In-Reply-To: <199706132056.NAA22863@george.lbl.gov> from "Jin Guojun[ITG]" at Jun 13, 97 01:56:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The problem has been narrowed to a very small program at below. > It appears to happen at subroutine level. That is, the open/freopn works > in main() program, but fails in subroutine. To replace the subroutine call > at line 7 in main(), marked /* replace HERE */, with the body of openread() , > then, program works. So, what can cause this problem? [ ... ] It's looks like you are hanging in the threads scheduler. When you butil your libraries, did you rebuild everything from scratch? If not, that may be your problem. I know that main is "different" in threads, but I don't understand why a subroutine call would cause it to fail when it doesn't fail in main. What happens if you link it without the threaded libc? Does it run OK? (Do you have one? Or are you running the very recently changed stuff?). If it does, there is apparently a hidden stack dependency bug which is being triggered by your code. Check the wrappers for the functions called by the functions you call. It may be that freopen() is not a happy camper in general, on the basis of descriptor locks, and you are only lucking out in main() when it works. Another thig to try is to take stdio out of the equation. I suspect that it is an implementation assumption in stdio that is biting you; it may in fact be a scheduler race which gets drawn out when you go down. If it's a race, make the variables global; if it still fails, you should then be able to migrate the code in and out of the subroutine a tine at a time to localise the error (part of this will be to compile the libc(3) pieces yourself, and migrate their function boundries as well). Sorry I can't give you an "oh, #define FROBOZZ" type soloution. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706132159.OAA11667>