bug#39118: Segfault while building on 64-bit Cygwin

bug#39118: Segfault while building on 64-bit Cygwin

[Ludovic Courtès]

Hi John,

John Cowan <cowan@ccil.org> skribis:

> Guile 2.9.9, like .8 and .7, does not build on Cygwin (64 bit).  Configure
> runs without error, but make crashes with this (truncated to just the tail):
>
> Making all in bootstrap
> make[2]: Entering directory
> '/cygdrive/c/Users/rr828893/Downloads/guile-2.9.9/bootstrap'
>   BOOTSTRAP GUILEC ice-9/eval.go
>   BOOTSTRAP GUILEC ice-9/psyntax-pp.go
>   BOOTSTRAP GUILEC language/cps/intmap.go
>   BOOTSTRAP GUILEC language/cps/intset.go
>   BOOTSTRAP GUILEC language/cps/graphs.go
>   BOOTSTRAP GUILEC ice-9/vlist.go
>   BOOTSTRAP GUILEC srfi/srfi-1.go
> /bin/sh: line 6:  4294 Segmentation fault      (core dumped)
> GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile
> --target="x86_64-unknown-cygwin" -O1 -Oresolve-primitives -L
> "/home/rr828893/Downloads/guile-2.9.9/module" -L
> "/home/rr828893/Downloads/guile-2.9.9/guile-readline" -o "srfi/srfi-1.go"
> "../module/srfi/srfi-1.scm"
> make[2]: *** [Makefile:1930: srfi/srfi-1.go] Error 139
> make[2]: Leaving directory
> '/cygdrive/c/Users/rr828893/Downloads/guile-2.9.9/bootstrap'
> make[1]: *** [Makefile:1849: all-recursive] Error 1
> make[1]: Leaving directory
> '/cygdrive/c/Users/rr828893/Downloads/guile-2.9.9'
> make: *** [Makefile:1735: all] Error 2

Could you try building 3.0.0 with JIT enabled and grab a backtrace?

Thanks in advance!

Ludo’.

bug#39118: Segfault while building on 64-bit Cygwin

[Mike Gran via Bug reports for GUILE, GNU's Ubiquitous Extension Language]

On Mon, Jan 20, 2020 at 11:38:35AM -0500, John Cowan wrote:
> Yes, gladly, but I don't know how to get one in this context.  Do I need to
> add some flags to the Makefile, and if so, where?  (It's a twisty maze of
> passages, all different.) . Note that this *is* a build with JIT enabled;
> when I disable it using the env variable, there are no errors and 3.0.0
> works fine.
> 
> Also, it may take some time, as I have to rebuild my Windows system.

I also tried building Guile 3.0.0 on Cygwin 3.1.x.  The failure comes from
trying to parse compiled .go files.

The last time that I had this sort of problem, it was because the
O_BINARY flag was dropped or missing when writing .go files, leading
to CR+LF characters in the compiled files.  And I diagnosed it by
byte-comparing Linux-compiled .go files with Cygwin-compiled .go
files, and by looking for CR+LF combinations in the compiled .go
files.

I don't know if that is what is happening here, but, I'll check that
next time I have a chance.

Thanks,
Michael

Re: bug#39118: Segfault while building on 64-bit Cygwin

[szgyg]

On Tue, Jan 21, 2020 at 10:01:58AM +0100, Ludovic Courtès wrote:
> but before that you’d run
> “ulimit -c unlimited” in that shell to make sure there’s a core dumped
> when it crashes.

This won't work on cygwin. If you want a core dump, you should use the
dumper tool, as described here
https://cygwin.com/cygwin-ug-net/dumper.html
Or you can set error_start to gdb to get an interactive gdb session on error.

s

Re: bug#39118: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

I'm no longer talking about Cygwin (which builds fine without JIT).  I'm
now talking about MacOS Catalina, which needs a core dump to debug, but on
which nobody seems to know how to enable core dumps.

On Tue, Jan 21, 2020 at 1:41 PM szgyg <szgyg@ludens.elte.hu> wrote:

> On Tue, Jan 21, 2020 at 10:01:58AM +0100, Ludovic Courtès wrote:
> > but before that you’d run
> > “ulimit -c unlimited” in that shell to make sure there’s a core dumped
> > when it crashes.
>
> This won't work on cygwin. If you want a core dump, you should use the
> dumper tool, as described here
> https://cygwin.com/cygwin-ug-net/dumper.html
> Or you can set error_start to gdb to get an interactive gdb session on
> error.
>
> s
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1161 bytes --]

RE: bug#39118: Segfault while building on 64-bit Cygwin

[dsmich]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

Pretty sure that the missing readline symbol is because the macos
readline is being used/found instead of GNU readline.

	-Dale

	-----------------------------------------From: "John Cowan" 
To: "Ludovic Courtès"
Cc: 39118@debbugs.gnu.org, guile-devel@gnu.org
Sent: Friday January 24 2020 9:36:59AM
Subject: bug#39118: Segfault while building on 64-bit Cygwin

Both Cygwin and MacOS crash in pretty much the same way. By disabling
the JIT, I was able to get the Cygwin build to run to completion. On
MacOS with --disable-jit, however, I am now getting an entirely new
failure:
 CC readline.lo
readline.c:432:7: warning: implicitly declaring library function
'strncmp' with type 'int (const char *, const char *,
 unsigned long)' [-Wimplicit-function-declaration]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^
readline.c:432:7: note: include the header  or explicitly provide a
declaration for 'strncmp'
readline.c:432:16: warning: implicit declaration of function
'rl_get_keymap_name' is invalid in C99
 [-Wimplicit-function-declaration]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^
readline.c:432:16: warning: incompatible integer to pointer conversion
passing 'int' to parameter of type 'const char *'
 [-Wint-conversion]
 if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 warnings generated.
 CCLD guile-readline.la [1]
Undefined symbols for architecture x86_64:
 "_rl_get_keymap_name", referenced from:
 _scm_init_readline in readline.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

On Thu, Jan 23, 2020 at 3:35 PM Ludovic Courtès  wrote:
Hi,

 John Cowan  skribis:

 > Thanks. Unfortunately, the standard recipe for making core dumps on
Mac

 This bug report is about Cygwin, not macOS, right? :-)

 Ludo’.
  

Links:
------
[1] http://guile-readline.la
[2] mailto:ludo@gnu.org
[3] mailto:cowan@ccil.org


[-- Attachment #2: Type: text/html, Size: 2891 bytes --]

bug#39118: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1.1: Type: text/plain, Size: 2195 bytes --]

Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows, after
all.  This is what I get when I specify ulimit -c unlimited and rebuild:

Exception: STATUS_ACCESS_VIOLATION at rip=0055A8B1B25
rax=0000000000000000 rbx=FFFFFFFFFFFFFF90 rcx=FFFFFFFFFFFFFF90
rdx=000000000034964A rsi=000007000084ECC0 rdi=FFFFFFFFFFFFFF90
r8 =000007000084ECC0 r9 =0000000000000002 r10=0000000100000000
r11=000000055A86B190 r12=0000000000000002 r13=000000055A931EA0
r14=000006FFFFFEF840 r15=0000000000000000
rbp=000000000034964A rsp=00000000FFFFBDA0
program=C:\Users\rr828893\Downloads\guile-3.0.0\libguile\.libs\guile.exe,
pid 62833, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

I can't imagine what you can make of that.

On Sat, Jan 25, 2020 at 10:54 AM John Cowan <cowan@ccil.org> wrote:

>
>
> On Sat, Jan 25, 2020 at 8:51 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
>
>> That I understand.  However, I was asking for the backtrace of the crash
>> on Cygwin when JIT is enabled.  Could you grab it?
>>
>
> 1. The wisdom of the Internet has not been able to figure out how to
> generate a core dump on MacOS 10.15.2 (Catalina).  The usual set of
> enabling steps can be performed without error, but still no core dump.
>
> 2. Until today I believed that there was no way to generate a Cygwin core
> dump.  I know now that there is, but I may not be able to test it until
> Monday.  I'll let you know, and hopefully that will provide insight into
> the MacOS problem as well.
>
> 3.  I will try to work further on the MacOS libffi problem (which surfaces
> when you do --disable-jit to bypass the above problem) to convince MacOS to
> use GNU libffi rather than the native one.  It probably has to do with
> pkg-config, which I barely understand.
>
> "All problems are config problems."
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
> We are lost, lost.  No name, no business, no Precious, nothing.  Only
> empty.
> Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
> fishes, for a poor creature, and they say death.  So wise they are; so
> just,
> so very just.  --Gollum
>

[-- Attachment #1.2: Type: text/html, Size: 3104 bytes --]

[-- Attachment #2: guile.exe.stackdump --]
[-- Type: application/octet-stream, Size: 544 bytes --]

Exception: STATUS_ACCESS_VIOLATION at rip=0055A8B1B25
rax=0000000000000000 rbx=FFFFFFFFFFFFFF90 rcx=FFFFFFFFFFFFFF90
rdx=000000000034964A rsi=000007000084ECC0 rdi=FFFFFFFFFFFFFF90
r8 =000007000084ECC0 r9 =0000000000000002 r10=0000000100000000
r11=000000055A86B190 r12=0000000000000002 r13=000000055A931EA0
r14=000006FFFFFEF840 r15=0000000000000000
rbp=000000000034964A rsp=00000000FFFFBDA0
program=C:\Users\rr828893\Downloads\guile-3.0.0\libguile\.libs\guile.exe, pid 62833, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

bug#39118: Segfault while building on 64-bit Cygwin

[szgyg]

On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows, after
> all.  This is what I get when I specify ulimit -c unlimited and rebuild:
> [...]

Please see my previous mail on how to get a real core dump on cygwin
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39118#28


>> On Sat, Jan 25, 2020 at 8:51 AM Ludovic Courtès <ludo@gnu.org> wrote:
>>
>>> That I understand.  However, I was asking for the backtrace of the crash
>>> on Cygwin when JIT is enabled.  Could you grab it?

#v+
  BOOTSTRAP GUILEC ice-9/eval.go
  BOOTSTRAP GUILEC ice-9/psyntax-pp.go
  BOOTSTRAP GUILEC language/cps/intmap.go
  BOOTSTRAP GUILEC language/cps/intset.go
  BOOTSTRAP GUILEC language/cps/graphs.go
  BOOTSTRAP GUILEC ice-9/vlist.go
  BOOTSTRAP GUILEC srfi/srfi-1.go

Thread 1 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7444.0x2640]
0x000000055a8b1b25 in scm_to_uint64 (val=val@entry=0xffffffffffffff90) at ../../guile-3.0.0/libguile/conv-uinteger.i.c:44
44        else if (SCM_BIGP (val))
(gdb) bt
#0  0x000000055a8b1b25 in scm_to_uint64 (val=val@entry=0xffffffffffffff90) at ../../guile-3.0.0/libguile/conv-uinteger.i.c:44
#1  0x000000055a86b1ea in scm_bytevector_copy_x (source=0x700000948620, source_start=0x34964a, target=0x700000907600, target_start=0x2, len=0xffffffffffffff90)
    at ../../guile-3.0.0/libguile/bytevectors.c:604
#2  0x00006ffffe743866 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

  BOOTSTRAP GUILEC language/tree-il.go

(gdb) bt
#0  0x000000055a8b1b25 in scm_to_uint64 (val=val@entry=0xffffffffffffff90)
    at ../../guile-3.0.0/libguile/conv-uinteger.i.c:44
#1  0x000000055a86b1ea in scm_bytevector_copy_x (source=0x70000055f160, source_start=0x34964a, target=0x700000808c90,
    target_start=0x2, len=0xffffffffffffff90) at ../../guile-3.0.0/libguile/bytevectors.c:604
#2  0x00006ffffe73f936 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

  BOOTSTRAP GUILEC language/tree-il/analyze.go

(gdb) bt
#0  0x000000055a8b1b25 in scm_to_uint64 (val=val@entry=0xffffffffffffff90)
    at ../../guile-3.0.0/libguile/conv-uinteger.i.c:44
#1  0x000000055a86b1ea in scm_bytevector_copy_x (source=0x700000645160, source_start=0x34964a, target=0x7000008012d0,
    target_start=0x2, len=0xffffffffffffff90) at ../../guile-3.0.0/libguile/bytevectors.c:604
#2  0x00006ffffe753fc6 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

^C
#v-

s

Re: bug#39118: Segfault while building on 64-bit Cygwin

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

On Mon, Feb 3, 2020 at 5:11 PM szgyg <szgyg@ludens.elte.hu> wrote:

On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> > Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows,
> after
> > all.  This is what I get when I specify ulimit -c unlimited and rebuild:
> > [...]
>
> Please see my previous mail on how to get a real core dump on cygwin
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39118#28


Okay, I looked at that page.  However, Cygwin's dumper requires you to know
the Windows PID of the process to dump.  Clearly it is intended for a
long-running process such as a server process, which you can force to core
dump, as if by "/bin/kill -SIGSEGV pid"; it is not suitable for a process
that gets a segmentation violation for internal reasons.  In any case, when
building, I have no idea of the pid of the process which is dumping; it
starts up and then dumps immediately.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
The Penguin shall hunt and devour all that is crufty, gnarly and
bogacious; all code which wriggles like spaghetti, or is infested with
blighting creatures, or is bound by grave and perilous Licences shall it
capture.  And in capturing shall it replicate, and in replicating shall
it document, and in documentation shall it bring freedom, serenity and
most cool froodiness to the earth and all who code therein.  --Gospel of Tux

[-- Attachment #2: Type: text/html, Size: 2122 bytes --]

Re: bug#39118: Segfault while building on 64-bit Cygwin

[szgyg]

On Wed, Feb 05, 2020 at 04:11:04PM -0500, John Cowan wrote:
> On Mon, Feb 3, 2020 at 5:11 PM szgyg <szgyg@ludens.elte.hu> wrote:
> 
> On Fri, Jan 31, 2020 at 09:23:19AM -0500, John Cowan wrote:
> > > Aaaand... Cygwin doesn't do core dumps. Under the skin it's WIndows,
> > after
> > > all.  This is what I get when I specify ulimit -c unlimited and rebuild:
> > > [...]
> >
> > Please see my previous mail on how to get a real core dump on cygwin
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39118#28
> 
> 
> Okay, I looked at that page.  However, Cygwin's dumper requires you to know
> the Windows PID of the process to dump.  Clearly it is intended for a
> long-running process such as a server process, which you can force to core
> dump, as if by "/bin/kill -SIGSEGV pid"; it is not suitable for a process
> that gets a segmentation violation for internal reasons.  In any case, when
> building, I have no idea of the pid of the process which is dumping; it
> starts up and then dumps immediately.


| One common way to use dumper is to plug it into cygwin's Just-In-Time
| debugging facility by adding
| error_start=x:\path\to\dumper.exe
| to the CYGWIN environment variable. Please note that x:\path\to\dumper.exe
| is Windows-style and not cygwin path. If error_start is set this way, then
| dumper will be started whenever some program encounters a fatal error.


s