Bug 259070 - devel/geany: crash then build with gcc
Summary: devel/geany: crash then build with gcc
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Guido Falsi
URL:
Keywords:
Depends on: 236344 246488
Blocks:
  Show dependency treegraph
 
Reported: 2021-10-11 12:43 UTC by Ivan Rozhuk
Modified: 2021-10-25 00:38 UTC (History)
1 user (show)

See Also:
madpilot: maintainer-feedback+


Attachments
Experimental patch (503 bytes, patch)
2021-10-11 15:37 UTC, Guido Falsi
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Rozhuk 2021-10-11 12:43:27 UTC
env USE_GCC=yes make deinstall install

~% geany
Segmentation fault (core dumped)
Exit 139


(lldb) bt all
* thread #1, name = 'geany', stop reason = signal SIGSEGV
  * frame #0: 0x00000008033a25d8 libcxxrt.so.1`vtable for __cxxabiv1::__si_class_type_info + 16
    frame #1: 0x00000008020a656a libstdc++.so.6`__dynamic_cast + 106
    frame #2: 0x00000008009e0490 libgeany.so.0`___lldb_unnamed_symbol3217$$libgeany.so.0 + 1984
    frame #3: 0x00000008008f807b libgeany.so.0`scintilla_send_message + 523
    frame #4: 0x00000008008b4929 libgeany.so.0`sci_get_lexer + 41
    frame #5: 0x00000008008788ae libgeany.so.0`___lldb_unnamed_symbol774$$libgeany.so.0 + 286
    frame #6: 0x0000000800878d38 libgeany.so.0`editor_create_widget + 856
    frame #7: 0x0000000800878f19 libgeany.so.0`___lldb_unnamed_symbol775$$libgeany.so.0 + 169
    frame #8: 0x0000000800865d09 libgeany.so.0`___lldb_unnamed_symbol657$$libgeany.so.0 + 521
    frame #9: 0x0000000800867c64 libgeany.so.0`document_new_file + 68
    frame #10: 0x000000080089d5ef libgeany.so.0`main_lib + 4127
    frame #11: 0x00000000004006f5 geany`___lldb_unnamed_symbol2$$geany + 277
    frame #12: 0x00000000004005f0 geany`___lldb_unnamed_symbol2$$geany + 16
  thread #2, name = 'gmain', stop reason = signal SIGSEGV
    frame #0: 0x000000080277c24a libc.so.7`__sys_poll + 10
    frame #1: 0x00000008007d7646 libthr.so.3`___lldb_unnamed_symbol157$$libthr.so.3 + 54
    frame #2: 0x0000000801e1e1a1 libglib-2.0.so.0`g_poll(fds=0x00000008039db448, nfds=1, timeout=-1) at gpoll.c:125:10
    frame #3: 0x0000000801e09dc2 libglib-2.0.so.0`g_main_context_poll(context=0x0000000803852c00, timeout=-1, priority=2147483647, fds=0x00000008039db448, n_fds=1) at gmain.c:4478:13
    frame #4: 0x0000000801e07767 libglib-2.0.so.0`g_main_context_iterate(context=0x0000000803852c00, block=1, dispatch=1, self=0x0000000803839cc0) at gmain.c:4170:3
    frame #5: 0x0000000801e07833 libglib-2.0.so.0`g_main_context_iteration(context=0x0000000803852c00, may_block=1) at gmain.c:4240:12
    frame #6: 0x0000000801e0966d libglib-2.0.so.0`glib_worker_main(data=0x0000000000000000) at gmain.c:6140:7
    frame #7: 0x0000000801e45028 libglib-2.0.so.0`g_thread_proxy(data=0x0000000803839cc0) at gthread.c:827:20
    frame #8: 0x00000008007cb970 libthr.so.3`___lldb_unnamed_symbol12$$libthr.so.3 + 320
  thread #3, name = 'pool-spawner', stop reason = signal SIGSEGV
    frame #0: 0x00000008007c8b4c libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 12
    frame #1: 0x00000008007d8dd0 libthr.so.3`___lldb_unnamed_symbol189$$libthr.so.3 + 80
    frame #2: 0x00000008007ca71d libthr.so.3`___lldb_unnamed_symbol8$$libthr.so.3 + 605
    frame #3: 0x0000000801e83f12 libglib-2.0.so.0`g_cond_wait(cond=0x0000000803f06908, mutex=0x0000000803f06900) at gthread-posix.c:792:6
    frame #4: 0x0000000801dbc980 libglib-2.0.so.0`g_async_queue_pop_intern_unlocked(queue=0x0000000803f06900, wait=1, end_time=-1) at gasyncqueue.c:419:6
    frame #5: 0x0000000801dbca8d libglib-2.0.so.0`g_async_queue_pop_unlocked(queue=0x0000000803f06900) at gasyncqueue.c:475:10
    frame #6: 0x0000000801e45849 libglib-2.0.so.0`g_thread_pool_spawn_thread(data=0x0000000000000000) at gthreadpool.c:315:27
    frame #7: 0x0000000801e45028 libglib-2.0.so.0`g_thread_proxy(data=0x0000000804872980) at gthread.c:827:20
    frame #8: 0x00000008007cb970 libthr.so.3`___lldb_unnamed_symbol12$$libthr.so.3 + 320
  thread #4, name = 'pool-geany', stop reason = signal SIGSEGV
    frame #0: 0x00000008007c8b4c libthr.so.3`___lldb_unnamed_symbol1$$libthr.so.3 + 12
    frame #1: 0x00000008007d8dd0 libthr.so.3`___lldb_unnamed_symbol189$$libthr.so.3 + 80
    frame #2: 0x00000008007ca71d libthr.so.3`___lldb_unnamed_symbol8$$libthr.so.3 + 605
    frame #3: 0x0000000801e84103 libglib-2.0.so.0`g_cond_wait_until(cond=0x0000000803f06388, mutex=0x0000000803f06380, end_time=245841652824) at gthread-posix.c:928:19
    frame #4: 0x0000000801dbc99a libglib-2.0.so.0`g_async_queue_pop_intern_unlocked(queue=0x0000000803f06380, wait=1, end_time=245841652824) at gasyncqueue.c:422:13
    frame #5: 0x0000000801dbccab libglib-2.0.so.0`g_async_queue_timeout_pop_unlocked(queue=0x0000000803f06380, timeout=500000) at gasyncqueue.c:574:10
    frame #6: 0x0000000801e46bc3 libglib-2.0.so.0`g_thread_pool_wait_for_new_task(pool=0x0000000803eaae00) at gthreadpool.c:278:18
    frame #7: 0x0000000801e4697a libglib-2.0.so.0`g_thread_pool_thread_proxy(data=0x0000000803eaae00) at gthreadpool.c:343:14
    frame #8: 0x0000000801e45028 libglib-2.0.so.0`g_thread_proxy(data=0x0000000804872d20) at gthread.c:827:20
    frame #9: 0x00000008007cb970 libthr.so.3`___lldb_unnamed_symbol12$$libthr.so.3 + 320
Comment 1 Guido Falsi freebsd_committer freebsd_triage 2021-10-11 14:59:11 UTC
Not sure how to react to this.

I confess I have no clue about this.

Looking at the PRs you linked makes me think maybe this should be addressed via some ports framework tool or addition to USES=compiler?

What happens if you change the "USES=compiler:c++11-lang" to "USES=compiler:c++11-lib"?

I'll add a patch to that effect after some testing but I'm not sure I can easily properly test with gcc.
Comment 2 Guido Falsi freebsd_committer freebsd_triage 2021-10-11 15:37:35 UTC
Created attachment 228588 [details]
Experimental patch

Attaching a very experimental patch implementing suggested test in comment #1

Please test is this helps.

Since building with gcc is non standard and no packages for any architecture are provided with such a setup I'd rather avoid bumping PORTREVISION for this issue.
Comment 3 Ivan Rozhuk 2021-10-11 17:25:29 UTC
Yes, probably this is not port specific.

Patch did not help.
May be there is no fix for this: I assume that some other lib loads clang lib that force use clang libc*** instead of gcc libc***.