annoying simple Guile question

[Perry Smith]

On some systems, there is either _exit() or kexit() that actually calls 
the OS's exit.  If you are on a unix type system and want to get really 
nasty, you can do kill(getpid(), SIGKILL);

But, even at that, a process can hang in the exit of the kernel.  The 
best example is if you have output going to a terminal and you type ^S 
so the output is buffered up, a Posix compliant system will not let the 
process exit until the data has drained out.


On Sep 21, 2004, at 3:11 PM, Derek Atkins wrote:

> Neil Williams <linux at codehelp.co.uk> writes:
>
>> When running a console application that uses guile via gnucash-env, 
>> how do I
>> abort?
>
> You mean how do you get the program to exit?  You call exit();
> in your C, or (exit) from guile.
>
>> I free the memory I used, I call gnc_engine_shutdown() but the 
>> program hangs,
>> waiting for a Ctrl-C. I've checked and all the usual tidying up 
>> functions are
>> called without errors - it exits normally when allowed to complete the
>> program, but if there's an error or if the user simply wants to 
>> abort, I
>> can't get it to exit.
>>
>> exit(1); is no help.
>
> Uh, this is how you exit from ANY C program...
>
>> I have put error handlers at the start of every function that would 
>> be called
>> after the abort to cause the function to return if abort is set, no 
>> odds.
>>
>> The code itself has changed many times but this problem has remained 
>> since I
>> started using it via guile to get access to the file backend to read 
>> the
>> QofBook data from external files. It's the example code here:
>> http://code.neil.williamsleesmill.me.uk/example-gncBookMerge.c
>> (the new home for my code - codehelp doesn't have the space)
>>
>> (gdb) continue
>> Continuing.
>>
>> Program received signal SIGINT, Interrupt.
>> [Switching to Thread 16384 (LWP 30982)]
>> 0x402b94fd in mallopt () from /lib/libc.so.6
>> #0  0x402b94fd in mallopt () from /lib/libc.so.6
>> #1  0x402b8d08 in mallopt () from /lib/libc.so.6
>> #2  0x402b7ef3 in malloc () from /lib/libc.so.6
>> #3  0x414ac2ee in operator new () from /usr/lib/libstdc++.so.5
>> #4  0x414ac41f in operator new[] () from /usr/lib/libstdc++.so.5
>> #5  0x415cd142 in OpenSP::String<char>::resize () from 
>> /usr/lib/libosp.so.4
>> #6  0x415ccf8c in OpenSP::FileOutputByteStream::flush ()
>>> From /usr/lib/libosp.so.4
>> #7  0x415ccf09 in OpenSP::FileOutputByteStream::close ()
>>> From /usr/lib/libosp.so.4
>> #8  0x415ccd40 in OpenSP::FileOutputByteStream::~FileOutputByteStream 
>> ()
>>> From /usr/lib/libosp.so.4
>> #9  0x41583c42 in OpenSP::CmdLineApp::closeFileErrorMessage ()
>>> From /usr/lib/libosp.so.4
>> #10 0x40272ae2 in exit () from /lib/libc.so.6
>> #11 0x4010451d in scm_init_guile () from /usr/lib/libguile.so.12
>> #12 0x4010420b in scm_boot_guile () from /usr/lib/libguile.so.12
>> #13 0x0804a2da in main_helper (closure=0x1, argc=1077375036, 
>> argv=0x4037703c)
>> at example-gncBookMerge.c:282
>> #14 0x4025cdc6 in __libc_start_main () from /lib/libc.so.6
>> #15 0x08049891 in ?? ()
>
> Uh, how/why are you using OpenSP?  It looks like OpenSP has an exit
> handler (via atexit()) which seems to be trying to flush a stream
> and hanging during a malloc call.
>
> Very odd -- you must be doing something different than GnuCash.
> Strangely, none of the other test programs have this problem, so I'd
> start looking at how you're being different than those.  I'd start
> with the tests in the file backend.
>
> I'll also note that you might have a dependency issue if you're trying
> to "load files" from src/engine/test.
>
> -derek
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>