On Tue, 14 Jun 2011, Sebastian Reitenbach wrote: > what I'm trying to solve is that when there is no backtrace() available on > the system, then gnustep-base tries to roll sth. on its own, where it then > just make the application "hang". This is used in the exception handling. I > want to port a sudoku generator/game which makes use of exception handling, > when generating the sudoku. > Letting gnustep-base use its hand-rolled backtrace generation, then it hangs. > Then I tried to use backtrace() from libexecinfo, and it crashes. Now Stuart > pointed me to the libbacktrace, and also there, it crashes. With > libbacktrace, the crash seems to be very similar to the one seen in > libexecinfo, crashing when calling __builtin_return_address() with a frame > larger than the number of frames available. I don't know whether this is a > problem in the gcc __builtin_return_address(), or with gnustep-base calling > backtrace. But as far as I can see from the manual of backtrace(), > gnustep-base seems to be correct. > > I tried this sudoku game on Linux, with using backtrace() from glibc, and > with using the gnustep-based hand rolled variant to get a backtrace. Both > work there, and right now I don't know who is at fault, and what/how to fix > it. > The thing I got it to work on OpenBSD was a: link against libexecinfo, and > use the patch to libexecinfo I sent earlier Today, and b: use the > gnustep-based hand rolled version of stack trace generation, but disable it > to not generate a backtrace. If I don't find a working solution to get it to > work with a backtrace, then I'll probably disable the backtrace generation in > gnustep-base, since its not that important feature I think...
Which makes me wonder if libexecinfo does work at all... -- Antoine
