From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.lisp.guile.user Subject: Re: guile-2.0 on mingw: the sequel Date: Sun, 25 Aug 2013 18:26:50 +0300 Message-ID: <83mwo5hjut.fsf@gnu.org> References: <83vc2wj4hz.fsf@gnu.org> <83li3siues.fsf@gnu.org> <838uzrioqr.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1377444423 32437 80.91.229.3 (25 Aug 2013 15:27:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Aug 2013 15:27:03 +0000 (UTC) Cc: guile-user@gnu.org To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Aug 25 17:27:05 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VDcDW-0002rU-OH for guile-user@m.gmane.org; Sun, 25 Aug 2013 17:27:02 +0200 Original-Received: from localhost ([::1]:46471 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDcDW-0000VR-9U for guile-user@m.gmane.org; Sun, 25 Aug 2013 11:27:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDcDJ-0000VK-6W for guile-user@gnu.org; Sun, 25 Aug 2013 11:26:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDcDD-0006Bu-7R for guile-user@gnu.org; Sun, 25 Aug 2013 11:26:49 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:45321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDcDC-0006Bm-VQ for guile-user@gnu.org; Sun, 25 Aug 2013 11:26:43 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MS300200EUJQ200@a-mtaout20.012.net.il> for guile-user@gnu.org; Sun, 25 Aug 2013 18:26:41 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MS3002DHEWHA9A0@a-mtaout20.012.net.il>; Sun, 25 Aug 2013 18:26:41 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10693 Archived-At: > Date: Sat, 24 Aug 2013 10:05:13 +0200 > From: Panicz Maciej Godek > Cc: "guile-user@gnu.org" > > 2013/8/24 Eli Zaretskii > > > > yes, it seems that this was the reason. So now the guile > > > interpreter runs properly, but I still have a problem with > > > running a program that, having been linked against > > > libguile, would call scm_with_guile or scm_init_guile, e.g. > > > === > > > #include > > > void hi(void *unused) { scm_puts("hello!\n", scm_current_output_port()); > > } > > > int main() { > > > scm_with_guile(hi, NULL); > > > return 0; > > > } > > > === > > > > Does this work on other platforms? (I know almost nothing about > > linking C programs with libguile; maybe your program has a bug, or you > > are missing some function call necessary for this to work?) > > > > > It's the simplest example I could come up with. > The same code executes properly (i.e. displays "hello!") on linux. I guess you didn't configure without threads on GNU/Linux, did you? If not, I suggest to try that, my impression is that Guile without threads is not used too much on Posix platforms. Anyway, I looked into this a bit. I can confirm that the simple program you mentioned the first time aborts due to "stack overflow" (the blurb about "application requesting runtime to terminate in an unusual way" is displayed when the application calls 'abort'). However, I think this is a bogus result of what was supposed to be a test for stack overflow. Here are the details: If I set a breakpoint in 'abort', I see this backtrace: #0 0x004c58d0 in abort () #1 0x004257ff in pre_init_throw () #2 0x0045903e in vm_regular_engine () #3 0x0045aca7 in scm_call_with_vm () #4 0x004254df in scm_throw () #5 0x00404f37 in scm_error_scm () #6 0x00404fa7 in scm_error () #7 0x004391ef in scm_report_stack_overflow () #8 0x0045abf1 in scm_c_vm_run () #9 0x0045af17 in scm_load_compiled_with_vm () #10 0x0043c1e0 in scm_primitive_load_path () #11 0x00404af6 in scm_load_startup_files () #12 0x00404e5c in scm_i_init_guile () #13 0x00402344 in scm_i_init_thread_for_guile () #14 0x00402519 in scm_init_guile () #15 0x004013c0 in main () at guile-hello.c:13 The stack check, SCM_CHECK_STACK, called by scm_c_vm_run, tests the current stack pointer against the stack base and stack limit. What I see is that the stack base of the main (and only) thread is zero, which of course will always fail any such test. Stepping through the initialization code code in scm_i_init_guile (specifically, guilify_self_1, where the first thread is recorded, including its stack base), it turns out that GC_get_stack_base, which is implemented in libgc, returns zero as the stack base. The rest is, as they say, history. I didn't have a debug build of libgc to step into its code, so I couldn't see what is going on there, and libgc has too many different implementations of GC_get_stack_base to guess from the sources which one is actually compiled in, and what goes wrong there. Perhaps you could step into GC_get_stack_base that on your system. Alternatively, a possible workaround is to disable stack checking, using scm_debug_options. I'm quite sure there's nothing wrong with the stack. In any case, the Guile that is built _is_ functional: I've built GNU Make with Guile support using it, and the resulting make.exe passes all the tests that exercise the Guile interface, which include invoking the Guile interpreter to evaluate expressions.