Ben Okopnik, le Sat 12 Jan 2008 13:38:25 -0500, a écrit : > > I've run this through gdb with handle SIGPIPE nopass, and then I > > wouldn't get the segfault. Digging a bit in the SIGPIPE handler showed > > me that it calls init_migemo(), which itself calls fclose(), which > > is not safe since that function is not in the list of signal-safe > > functions. I commented these fclose() calls, and now I can't reproduce > > the bug any more. I'll keep that "fixed" version of w3m for some more > > long-term testing, but I really think the problem is here: I guess that > > fclose() frees something, so that it may corrupt the heap, thus the > > segfault on the next malloc (which happens to be due to searching the > > page). So the solution is probably to have the signal handler just set > > a variable and move the call to init_migemo into the main stream of > > instruction. > > I'd wonder what's going to be left open as a result of those two > "fclose()" calls not happening. I'd hate to see you create more > problems by fixing this one. :)
Sure, my patch wasn't meant to be any proper fix, but just a way to show the precise bits that poses problem. > Is there a signal-safe way of releasing those handles? No, the FILE structure is essentially a non-signal-safe structure. The only proper solution (which should probably be made upstream) is to set a volatile variable from the handler, and from the main loop detect that and call the fclose. Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
