Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

trying to compile on os x fails #5

Open
yannick opened this issue Sep 21, 2015 · 1 comment
Open

trying to compile on os x fails #5

yannick opened this issue Sep 21, 2015 · 1 comment

Comments

@yannick
Copy link

yannick commented Sep 21, 2015

tried to compile on os x.
i used

CC=gcc-5 CFLAGS=-Wno-error=deprecated-declarations ./configure
CC=gcc-5  make

after applying
https://lists.gnu.org/archive/html/bug-binutils/2015-07/msg00184.html
(which seems to have not been included?). i get the following error:

d-lang.c: In function 'd_make_symbol_completion_list':
d-lang.c:319:61: error: dereferencing pointer to incomplete type 'struct using_direct'
   for (current = imports; current != NULL; current = current->next)
                                                             ^
d-lang.c: In function 'dynamic_array_p':
d-lang.c:435:7: error: implicit declaration of function 'CHECK_TYPEDEF' [-Werror=implicit-function-declaration]
       CHECK_TYPEDEF (type0);
       ^
cc1: all warnings being treated as errors
make[2]: *** [d-lang.o] Error 1
make[1]: *** [all-gdb] Error 2
make: *** [all] Error 2

tried to add -Wno-implicit-function-declaration"
but then i get:

d-lang.c: In function 'd_make_symbol_completion_list':
d-lang.c:319:61: error: dereferencing pointer to incomplete type 'struct using_direct'
   for (current = imports; current != NULL; current = current->next)
                                                             ^
make[2]: *** [d-lang.o] Error 1
make[1]: *** [all-gdb] Error 2
make: *** [all] Error 2
@ibuclaw
Copy link
Owner

ibuclaw commented Sep 21, 2015

Much of what is here has been merged upstream, I don't actively downstream patches here much anymore.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git

ibuclaw pushed a commit that referenced this issue Sep 26, 2015
@palves
Fix gdbserver crash exposed by gdb.threads/process-dies-while-handlin…
465a859 
…g-bp.exp

Running that test in a loop, I found a gdbserver core dump with the
following back trace:

 Core was generated by `../gdbserver/gdbserver --once --multi :2346'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
 236       return inferior->regcache_data;
 (gdb) up
 #1  0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
 31        regcache = (struct regcache *) inferior_regcache_data (thread);
 (gdb) bt
 #0  0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
 #1  0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
 #2  0x0000000000409271 in prepare_resume_reply (buf=0x20dd593 "", ptid=..., status=0x20edce0) at src/gdb/gdbserver/remote-utils.c:1147
 #3  0x000000000040ab0a in vstop_notif_reply (event=0x20edcc0, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/server.c:183
 #4  0x0000000000426b38 in notif_write_event (notif=0x66e6c0 <notif_stop>, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/notif.c:69
 #5  0x0000000000426c55 in handle_notif_ack (own_buf=0x20dd590 "T05", packet_len=8) at src/gdb/gdbserver/notif.c:113
 #6  0x000000000041118f in handle_v_requests (own_buf=0x20dd590 "T05", packet_len=8, new_packet_len=0x7fff742c77b8)
     at src/gdb/gdbserver/server.c:2862
 #7  0x0000000000413850 in process_serial_event () at src/gdb/gdbserver/server.c:4148
 #8  0x0000000000413945 in handle_serial_event (err=0, client_data=0x0) at src/gdb/gdbserver/server.c:4196
 #9  0x000000000041a1ef in handle_file_event (event_file_desc=5) at src/gdb/gdbserver/event-loop.c:429
 #10 0x00000000004199b6 in process_event () at src/gdb/gdbserver/event-loop.c:184
 #11 0x000000000041a735 in start_event_loop () at src/gdb/gdbserver/event-loop.c:547
 #12 0x00000000004123d2 in captured_main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3562
 #13 0x000000000041252e in main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3631

Clearly this means that a thread pushed a stop reply in the event
queue, and then before GDB confused the event, the whole process died,
along with its thread.  But the pending thread event was left
dangling.  When GDB fetched that event, gdbserver looked up the
corresponding thread, but found NULL; not expecting this, gdbserver
crashes when it tries to read this thread's registers.

gdb/gdbserver/
2015-08-21  Pedro Alves  <[email protected]>

	PR gdb/18749
	* inferiors.c (remove_thread): Discard any pending stop reply for
	this thread.
	* server.c (remove_all_on_match_pid): Rename to ...
	(remove_all_on_match_ptid): ... this.  Work with a filter ptid
	instead of a pid.
	(discard_queued_stop_replies): Change parameter to a ptid.  Now
	extern.
	(handle_v_kill, kill_inferior_callback)
	(process_serial_event): Adjust.
	(captured_main): Call initialize_notif before starting the
	program, thus before threads are created.
	* server.h (discard_queued_stop_replies): Declare.
ibuclaw pushed a commit that referenced this issue Apr 10, 2017
Don't delete thread_info if refcount isn't zero
803bdfe 
I build GDB with asan, and run test case hook-stop.exp, and threadapply.exp,
I got the following asan error,

=================================================================^M
^[[1m^[[31m==2291==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000999c4 at pc 0x000000826022 bp 0x7ffd28a8ff70 sp 0x7ffd28a8ff60^M
^[[1m^[[0m^[[1m^[[34mREAD of size 4 at 0x6160000999c4 thread T0^[[1m^[[0m^M
    #0 0x826021 in release_stop_context_cleanup ../../binutils-gdb/gdb/infrun.c:8203^M
    #1 0x72798a in do_my_cleanups ../../binutils-gdb/gdb/common/cleanups.c:154^M
    #2 0x727a32 in do_cleanups(cleanup*) ../../binutils-gdb/gdb/common/cleanups.c:176^M
    #3 0x826895 in normal_stop() ../../binutils-gdb/gdb/infrun.c:8381^M
    #4 0x815208 in fetch_inferior_event(void*) ../../binutils-gdb/gdb/infrun.c:4011^M
    #5 0x868aca in inferior_event_handler(inferior_event_type, void*) ../../binutils-gdb/gdb/inf-loop.c:44^M
....
^[[1m^[[32m0x6160000999c4 is located 68 bytes inside of 568-byte region [0x616000099980,0x616000099bb8)^M
^[[1m^[[0m^[[1m^[[35mfreed by thread T0 here:^[[1m^[[0m^M
    #0 0x7fb0bc1312ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca)^M
    #1 0xb8c62f in xfree(void*) ../../binutils-gdb/gdb/common/common-utils.c:100^M
    #2 0x83df67 in free_thread ../../binutils-gdb/gdb/thread.c:207^M
    #3 0x83dfd2 in init_thread_list() ../../binutils-gdb/gdb/thread.c:223^M
    #4 0x805494 in kill_command ../../binutils-gdb/gdb/infcmd.c:2595^M
....

Detaching from program: /home/yao.qi/SourceCode/gnu/build-with-asan/gdb/testsuite/outputs/gdb.threads/threadapply/threadapply, process 2399^M
=================================================================^M
^[[1m^[[31m==2387==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000a98c0 at pc 0x00000083fd28 bp 0x7ffd401c3110 sp 0x7ffd401c3100^M
^[[1m^[[0m^[[1m^[[34mREAD of size 4 at 0x6160000a98c0 thread T0^[[1m^[[0m^M
    #0 0x83fd27 in thread_alive ../../binutils-gdb/gdb/thread.c:741^M
    #1 0x844277 in thread_apply_all_command ../../binutils-gdb/gdb/thread.c:1804^M
....
^M
^[[1m^[[32m0x6160000a98c0 is located 64 bytes inside of 568-byte region [0x6160000a9880,0x6160000a9ab8)^M
^[[1m^[[0m^[[1m^[[35mfreed by thread T0 here:^[[1m^[[0m^M
    #0 0x7f59a7e322ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca)^M
    #1 0xb8c62f in xfree(void*) ../../binutils-gdb/gdb/common/common-utils.c:100^M
    #2 0x83df67 in free_thread ../../binutils-gdb/gdb/thread.c:207^M
    #3 0x83dfd2 in init_thread_list() ../../binutils-gdb/gdb/thread.c:223^M

This patch fixes the issue by deleting thread_info object if it is
deletable, otherwise, mark it as exited (by set_thread_exited).
Function set_thread_exited is shared from delete_thread_1.  This patch
also moves field "refcount" to private and methods incref and
decref.  Additionally, we stop using "ptid_t" in
"struct current_thread_cleanup" to reference threads, instead we use
"thread_info" directly.  Due to this change, we don't need
restore_current_thread_ptid_changed anymore.

gdb:

2017-04-10  Yao Qi  <[email protected]>

	PR gdb/19942
	* gdbthread.h (thread_info::deletable): New method.
	(thread_info::incref): New method.
	(thread_info::decref): New method.
	(thread_info::refcount): Move it to private.
	* infrun.c (save_stop_context): Call inc_refcount.
	(release_stop_context_cleanup): Likewise.
	* thread.c (set_thread_exited): New function.
	(init_thread_list): Delete "tp" only it is deletable, otherwise
	call set_thread_exited.
	(delete_thread_1): Call set_thread_exited.
	(current_thread_cleanup) <inferior_pid>: Remove.
	<thread>: New field.
	(restore_current_thread_ptid_changed): Removed.
	(do_restore_current_thread_cleanup): Adjust.
	(restore_current_thread_cleanup_dtor): Don't call
	find_thread_ptid.
	(set_thread_refcount): Use dec_refcount.
	(make_cleanup_restore_current_thread): Adjust.
	(thread_apply_all_command): Call inc_refcount.
	(_initialize_thread): Don't call
	observer_attach_thread_ptid_changed.
@katastic katastic mentioned this issue Nov 23, 2017
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@yannick @ibuclaw