From: Silas S. <si...@gm...> - 2010-11-01 03:12:27
|
Hi all! FreeCAD is the first program I know that intercepts SIGSEGV. Is there any purpose about that? The message "Illegal storage access..." is not to much clear comparing to "Memory fault (Core dumped)". Actually it is more confusing for who knows what a memory fault is. Ah, and it seems to avoid the creation of core files, at least on NetBSD. One more thing. The Single Unix Specification (http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03) says that intercepting SIGSEGV has undefined behaviour on the process. Should we avoid that? Thanks! P.S.: Actually, I don't see any usefulness of segmentation_fault_handler()... -- Silas Silva |
From: Werner M. <wer...@gm...> - 2010-11-14 09:25:30
|
Hi, Am 12.11.2010 12:24, Silas Silva wrote: > Hi Werner! > > On Tue, Nov 02, 2010 at 10:04:43AM +0100, Werner Mayer wrote: > >>> FreeCAD is the first program I know that intercepts SIGSEGV. Is >>> there any purpose about that? The message "Illegal storage >>> access..." is not to much clear comparing to "Memory fault (Core >>> dumped)". Actually it is more confusing for who knows what a memory >>> fault is. >>> >> The intention was to dump a message into a log file if FreeCAD was >> started with --write-log. Therefore we have also implemented a class >> to redirect streams that goes to std::cerr, std::cout and std::clog >> and redirect them to our Base::Console class. >> > Hmmm, interesting. So, --write-log just redirects stdout and stderr? > Exactly! > >> Does it? The text says: >> >> The behavior of a process is undefined after it returns normally from >> a signal-catching function for a SIGBUS, SIGFPE, SIGILL, or SIGSEGV >> signal that was not generated by kill(), sigqueue(), or raise(). >> >> But we do NOT return normally because we close the application. >> > You are right, sorry, bad English here, so I couldn't get the real > meaning of th text. > > >> You say that it avoids the creation of core dumps. What about doing it this way then? >> 1. store the old handler when doing std::signal(...) >> 2. inside our handler we first print the error message and then call the original from within our handler. >> > Thanks for the tip. I'm actually without time to muck around on FreeCAD > these days, but I hope I'll have that time soon. > I tried it that way but unfortunately the std::signal returns 0. BTW, I have replaced the fcvt() function using some stream manipulators which even made the code much more readable. > Thanks again! > > Cheers |