After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 571037 - valac segv/stackoverflow in vala_code_context_find_cycle_head (testcase attached)
valac segv/stackoverflow in vala_code_context_find_cycle_head (testcase attac...
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: general
0.5.x
Other All
: Normal critical
: ---
Assigned To: Jürg Billeter
Vala maintainers
Depends on: 572536
Blocks:
 
 
Reported: 2009-02-09 11:08 UTC by Martin Olsson
Modified: 2009-03-30 22:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
testcase (run "vala -C *.vala" to trigger SEGV) (332 bytes, application/x-compressed-tar)
2009-02-09 11:09 UTC, Martin Olsson
Details

Description Martin Olsson 2009-02-09 11:08:29 UTC
Steps to reproduce:
1. download testcase and extract both .vala files
2. install vala 0.5.6 (also works on trunk as of today)
3. run "valac -C *.vala"


Stack trace:


Other information:
Comment 1 Martin Olsson 2009-02-09 11:09:13 UTC
Created attachment 128284 [details]
testcase (run "vala -C *.vala" to trigger SEGV)
Comment 2 Martin Olsson 2009-02-09 11:13:00 UTC
(note: putting the code into a single .vala file makes the bug go away)

The backtrace is a near endless list of frames like these:

  • #0 _int_memalign
    from /lib/libc.so.6
  • #1 memalign
    from /lib/libc.so.6
  • #2 posix_memalign
    from /lib/libc.so.6
  • #3 slab_allocator_alloc_chunk
    at /build/buildd/glib2.0-2.19.6/glib/gslice.c line 1136
  • #4 IA__g_slice_alloc
    at /build/buildd/glib2.0-2.19.6/glib/gslice.c line 666
  • #5 IA__g_slice_alloc0
    at /build/buildd/glib2.0-2.19.6/glib/gslice.c line 833
  • #6 IA__g_type_create_instance
    at /build/buildd/glib2.0-2.19.6/gobject/gtype.c line 1654
  • #7 gee_array_list_real_iterator
    at arraylist.c line 365
  • #8 vala_code_context_find_cycle_head
    at valacodecontext.c line 371
  • #9 vala_code_context_find_cycle_head
    at valacodecontext.c line 380
  • #10 vala_code_context_find_cycle_head
    at valacodecontext.c line 380
  • #11 vala_code_context_find_cycle_head
    at valacodecontext.c line 380
  • #12 vala_code_context_find_cycle_head
    at valacodecontext.c line 380
  • #35934 vala_code_context_find_cycle_head
    at valacodecontext.c line 380
  • #35935 vala_code_context_find_cycle_head
    at valacodecontext.c line 380
  • #35936 vala_code_context_find_cycle_head
    at valacodecontext.c line 380
  • #35937 vala_code_context_find_cycle_head
    at valacodecontext.c line 380


While running it in nemiver, basically vala_code_context_find_cycle_head calls itself
on line 380 once the inner while loop reaches its second iteration. FWIW, if the alternating
file=BLAH pointer is dereferenced (and also its "priv" field) inside it then what
I see is that the filename field is set to the same thing in the 0x1673290 object and
the 0x1673360 object.
Comment 3 Martin Olsson 2009-03-26 17:27:58 UTC
still repros on vala git HEAD as of today
Comment 4 Jürg Billeter 2009-03-30 22:36:15 UTC
commit 2d4a4a264677b42710914907f63e1624e25e560f
Author: Jürg Billeter <j@bitron.ch>
Date:   Tue Mar 31 00:31:07 2009 +0200

    Rework header file generation
    
    Generate single C header file for public API, do not use header
    files for internal API. Fixes bug 471244, bug 571037, bug 572536,
    and bug 575629.