mainBison - Support: sr #110539, bison segv under Cygwin 64 in...

 
 

sr #110539: bison segv under Cygwin 64 in fatal-signal.c:318

Submitter:  None
Submitted:  Sun 12 Sep 2021 06:03:14 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  None
Privacy:  Public Assigned to:  akim
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  Microsoft Windows
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 10 Sep 2022 12:23:57 PM UTC, comment #1: 

Hi,

I'm sorry I didn't pay attention to your issue sooner.

Do you still have the problem with the latest release (3.7.2)?  If you do, could you please try the following tarball, which is our current master.

https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.2.37-dd6c.tar.gz  5.8M
https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.2.37-dd6c.tar.lz  3.1M
https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.2.37-dd6c.tar.xz  3.1M

Please, we prefer bug report sent to bug-bison@gnu.org.

Cheers!

Akim Demaille <akim>
Group administrator
Sun 12 Sep 2021 06:03:14 PM UTC, original submission:  

Trying to package bison 3.8/.1 for Cygwin - previous releases to 3.7.6 built and checked okay - bison 3.8.1 checked okay on 32 bit - all tests segv on 64 bit!

Reran build and check with bison 3.8 and 3.8.1 using gcc 10.2.0 and 11.2.0 with no change in all tests segv @ 0x0000000100000000.

Build runs with autoreconf et al as per normal on 32 and 64 bit; adding debug output allowed me see test commands to narrow down cause.

Ran using gdb against tests/c/bistromathic/parse.y (see attached for gdb command, script, and full log) getting the output below.

It appears to be possible that `gl_lock_lock` expansion to `pthread_in_use() ? pthread_mutex_lock(...)` -> glthread_in_use() ? ...` has avoided defining the latter in the build, or some underlying dynamic library function may not be loaded?

Thread 1 "bison" hit Breakpoint 10, block_fatal_signals () at /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c:318
318       if (mt) gl_lock_lock (fatal_signals_block_lock);
Continuing.

Thread 1 "bison" received signal SIGSEGV, Segmentation fault.
0x0000000100000000 in ?? ()
#0  0x0000000100000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #51897:  bison-segv-cygwin-64-gdb.sh added by None (223B - text/x-sh - Attached gdb invocation command, gdb commands setup script, and gdb output log)
file #51898:  bison-segv-cygwin-64.gdb added by None (1KiB - application/octet-stream - Attached gdb invocation command, gdb commands setup script, and gdb output log)
file #51899:  bison-segv-cygwin-64-gdb.log added by None (4KiB - application/octet-stream - Attached gdb invocation command, gdb commands setup script, and gdb output log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by akim (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-10 akim Assigned toNone akim
    2021-09-12 None Attached File- Added bison-segv-cygwin-64-gdb.sh, #51897
        Attached File- Added bison-segv-cygwin-64.gdb, #51898
        Attached File- Added bison-segv-cygwin-64-gdb.log, #51899

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code