Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Jun 1997 15:26:20 -0700
From:      "Jin Guojun[ITG]" <jin@george.lbl.gov>
To:        lambert.org!terry@agora.rdrop.com
Cc:        bugs@FreeBSD.ORG, smp@FreeBSD.ORG, smp@csn.net
Subject:   Re: (kern/3827) : was ASUS P/I-P65UP5 with C-P55T2D
Message-ID:  <199706132226.PAA24417@george.lbl.gov>

next 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 did not do anything with the libraries. They come with the 3.0-SNAP
distribution.

}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.

That is the strange part. Our most programs are not failure because
they start fopen/freopen at main(), and the complicated programs are
invoking the fopen/freopen in subroutines, which typically in threaded
subroutines.

So, at the beginning, I thought the hanging was related when the program
growing in size. So, I wrote a small program -- openread -- in a main()
style that works. Then, I tried to make it called from the program failed
at fopen/freopen. This needs make openread() to be a subroutine. At this
time, the simple program fails. So, it is not the program size issue.
Since the openread.c is so small, the only thing I saw is fopen/freopen
fails in subroutine.

}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?).

That is not the problem. The problem happens only linked to libc_r, which
is defaulted to distribution of 3.0-xxx. Without -lc_r, everything is OK.

}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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706132226.PAA24417>