Open oldsharp opened 8 years ago
likely a bug of alpine. since proxychains is by default built with debug info it should be sufficient to rebuild alpine with debug info and then debug it as you did in your first paste, however when lldb stops for exec you need to continue and wait for the segv.
That's embarrassing I forgot to continue... Anyway, here's the result:
$ lldb proxychains4
(lldb) target create "proxychains4"
Current executable set to 'proxychains4' (x86_64).
(lldb) run /usr/local/bin/alpine
Process 8804 launched: '/usr/local/bin/proxychains4' (x86_64)
[proxychains] config file found: /Users/ray/.proxychains/proxychains.conf
[proxychains] preloading /usr/local/Cellar/proxychains-ng/4.11/lib/libproxychains4.dylib
Process 8804 stopped
* thread #1: tid = 0x227b6, 0x00007fff5fc01000 dyld`_dyld_start, stop reason = exec
frame #0: 0x00007fff5fc01000 dyld`_dyld_start
dyld`_dyld_start:
-> 0x7fff5fc01000 <+0>: popq %rdi
0x7fff5fc01001 <+1>: pushq $0x0
0x7fff5fc01003 <+3>: movq %rsp, %rbp
0x7fff5fc01006 <+6>: andq $-0x10, %rsp
(lldb) c
Process 8804 resuming
Process 8804 stopped
* thread #1: tid = 0x227b6, 0x00007fff9955ca1f libheimdal-asn1.dylib`der_free_integer + 4, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff9955ca1f libheimdal-asn1.dylib`der_free_integer + 4
libheimdal-asn1.dylib`der_free_integer:
-> 0x7fff9955ca1f <+4>: movl $0x0, (%rdi)
0x7fff9955ca25 <+10>: popq %rbp
0x7fff9955ca26 <+11>: retq
libheimdal-asn1.dylib`der_free_unsigned:
0x7fff9955ca27 <+0>: pushq %rbp
(lldb) bt all
* thread #1: tid = 0x227b6, 0x00007fff9955ca1f libheimdal-asn1.dylib`der_free_integer + 4, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x00007fff9955ca1f libheimdal-asn1.dylib`der_free_integer + 4
frame #1: 0x00007fff9956037d libheimdal-asn1.dylib`_asn1_free + 246
frame #2: 0x00007fff995603c0 libheimdal-asn1.dylib`_asn1_free + 313
frame #3: 0x00007fff9956042b libheimdal-asn1.dylib`_asn1_free + 420
frame #4: 0x00007fff995603c0 libheimdal-asn1.dylib`_asn1_free + 313
frame #5: 0x00007fff995603c0 libheimdal-asn1.dylib`_asn1_free + 313
frame #6: 0x00007fff9956042b libheimdal-asn1.dylib`_asn1_free + 420
frame #7: 0x00007fff995603c0 libheimdal-asn1.dylib`_asn1_free + 313
frame #8: 0x00007fff995603c0 libheimdal-asn1.dylib`_asn1_free + 313
frame #9: 0x00007fff9955f77e libheimdal-asn1.dylib`_asn1_free_top + 18
frame #10: 0x00007fff9d967bad Heimdal`krb5_free_principal + 22
frame #11: 0x00007fff969bf6a3 Kerberos`krb5_free_principal + 51
frame #12: 0x00007fffa1583722 GSS`_gsskrb5_release_name + 66
frame #13: 0x00007fffa158c99c GSS`_gss_mg_release_name + 63
frame #14: 0x00007fff9296c0a3 CoreFoundation`CFRelease + 371
frame #15: 0x00007fffa158d018 GSS`gss_release_name + 35
frame #16: 0x00000001001ad0f9 alpine`auth_gssapi_valid + 200
frame #17: 0x00000001001c9102 alpine`auth_link + 28
frame #18: 0x000000010001ec47 alpine`main + 1159
frame #19: 0x00007fff968085ad libdyld.dylib`start + 1
frame #20: 0x00007fff968085ad libdyld.dylib`start + 1
thread #2: tid = 0x227d5, 0x00007fffa124f176 libsystem_kernel.dylib`__select + 10
frame #0: 0x00007fffa124f176 libsystem_kernel.dylib`__select + 10
frame #1: 0x0000000100557aa6 libproxychains4.dylib`getmessage + 129
frame #2: 0x0000000100557cbc libproxychains4.dylib`threadfunc + 56
frame #3: 0x00007fff9a702c13 libsystem_pthread.dylib`_pthread_body + 131
frame #4: 0x00007fff9a702b90 libsystem_pthread.dylib`_pthread_start + 168
frame #5: 0x00007fff9a700375 libsystem_pthread.dylib`thread_start + 13
thread #4: tid = 0x227d7, 0x00007fffa124fff6 libsystem_kernel.dylib`kevent_qos + 10, queue = 'com.apple.libdispatch-manager'
frame #0: 0x00007fffa124fff6 libsystem_kernel.dylib`kevent_qos + 10
frame #1: 0x00007fff99322099 libdispatch.dylib`_dispatch_mgr_invoke + 216
frame #2: 0x00007fff99321d01 libdispatch.dylib`_dispatch_mgr_thread + 52
Googled with the EXC_I386_GPFLT
error code and found this thread on stackoverflow.
Hope this is helpful to address the issue.
looks like a double-free bug in the app
maybe try the same version you used on linux or report the bug to the devs. it's almost certain the bug happens without proxychains as well
maybe try the same version you used on linux
The Alpine version on my Linux box is exactly the same as the one I used on my Mac. In fact they were built from the same copy of source code, on different platform.
What I tried: linux-src-build, osx-homebrew, osx-src-build, all of them are alpine v2.20, built from exactly the same source code.
it's almost certain the bug happens without proxychains as well
It turned out the Linux one worked well (no matter with or without proxychains), while the Mac one crashed every time I ran it with proxychains, as the Homebrew's Alpine did.
Another wired thing is, if I try to run alpine
alone on Mac (without proxychains), it will not crash.
or report the bug to the devs
Yes I will try to contact the current maintainer of Alpine to report the problem.
you may try with current git; a problem was fixed that may be the cause of this.
Tried with 635ded3 but still got Segmentation fault: 11
.
Found func call that trigger EXC_I386_GPFLT:
(lldb) thread step-over
Process 62446 stopped
* thread #2, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000100359f93 alpine`auth_gssapi_valid at auth_gss.c:76
73 GSS_S_COMPLETE) return NIL;
74 /* remove server method if no keytab */
75 if (!kerberos_server_valid ()) auth_gss.server = NIL;
-> 76 gss_release_name (&smn,&name);/* finished with name */
77 return LONGT;
78 }
79
Target 0: (alpine) stopped.
(lldb) thread step-in
Process 62446 stopped
* thread #2, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff5cd02d50 libheimdal-asn1.dylib`der_free_integer + 4
libheimdal-asn1.dylib`der_free_integer:
-> 0x7fff5cd02d50 <+4>: movl $0x0, (%rdi)
0x7fff5cd02d56 <+10>: popq %rbp
0x7fff5cd02d57 <+11>: retq
libheimdal-asn1.dylib`der_free_unsigned:
0x7fff5cd02d58 <+0>: pushq %rbp
Target 0: (alpine) stopped.
(lldb) thread backtrace
* thread #2, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x00007fff5cd02d50 libheimdal-asn1.dylib`der_free_integer + 4
frame #1: 0x00007fff5cd06574 libheimdal-asn1.dylib`_asn1_free + 452
frame #2: 0x00007fff5cd06544 libheimdal-asn1.dylib`_asn1_free + 404
frame #3: 0x00007fff5cd06458 libheimdal-asn1.dylib`_asn1_free + 168
frame #4: 0x00007fff5cd06544 libheimdal-asn1.dylib`_asn1_free + 404
frame #5: 0x00007fff5cd06544 libheimdal-asn1.dylib`_asn1_free + 404
frame #6: 0x00007fff5cd06458 libheimdal-asn1.dylib`_asn1_free + 168
frame #7: 0x00007fff5cd06544 libheimdal-asn1.dylib`_asn1_free + 404
frame #8: 0x00007fff5cd06544 libheimdal-asn1.dylib`_asn1_free + 404
frame #9: 0x00007fff5cd0593e libheimdal-asn1.dylib`_asn1_free_top + 18
frame #10: 0x00007fff500881c6 Heimdal`krb5_free_principal + 22
frame #11: 0x00007fff3a62fc8a Kerberos`krb5_free_principal + 51
frame #12: 0x00007fff38f75108 GSS`_gsskrb5_release_name + 66
frame #13: 0x00007fff38f75066 GSS`_gss_mg_release_name + 63
frame #14: 0x00007fff36b54dac CoreFoundation`_CFRelease + 284
frame #15: 0x00007fff38f75023 GSS`gss_release_name + 35
frame #16: 0x0000000100359f98 alpine`auth_gssapi_valid at auth_gss.c:76
frame #17: 0x000000010038abd2 alpine`auth_link(auth=0x0000000100646f50) at mail.c:6129
frame #18: 0x0000000100030e94 alpine`main(argc=1, argv=0x00007ffeefbff2a0) at linkage.c:16
frame #19: 0x00007fff5e2cc115 libdyld.dylib`start + 1
gss_release_name
is an API of GSS.
While the exact reason is still unknown, there are some ways to workaround this issue.
maybe you can describe the workaround, so others can benefit from it as well ?
See https://github.com/oldsharp/alpine/commit/b02a039fce741bcaa5b1d96ca44eb9888c0d6669 for one possible solution.
i add your patch here inline so its recorded:
From b02a039fce741bcaa5b1d96ca44eb9888c0d6669 Mon Sep 17 00:00:00 2001
From: oldsharp <oldsharp@xxxx>
Date: Thu, 14 Dec 2017 22:59:41 +0800
Subject: [PATCH] Workaround the EXC_I386_GPFLT failure on macOS
macOS only:
When launch alpine together with proxychains4, a gss_release_name()
call after a gss_import_name() call will always fail with the error
code EXC_I386_GPFLT.
While the real reason is still unknown, comment out the related code
to workaround the failure.
Configure How-To (macOS with brewed OpenSSL):
- To enable debug:
$ ./configure \
--disable-optimization \
--prefix=/usr/local \
--with-ssl-dir=/usr/local/opt/openssl \
--with-ssl-certs-dir=/usr/local/etc/openssl
- Regular build:
$ ./configure \
--disable-debug \
--prefix=/usr/local \
--with-ssl-dir=/usr/local/opt/openssl \
--with-ssl-certs-dir=/usr/local/etc/openssl
---
imap/src/c-client/auth_gss.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/imap/src/c-client/auth_gss.c b/imap/src/c-client/auth_gss.c
index 66be8cc..99856d1 100644
--- a/imap/src/c-client/auth_gss.c
+++ b/imap/src/c-client/auth_gss.c
@@ -69,11 +69,11 @@ long auth_gssapi_valid (void)
mylocalhost ());
buf.length = strlen (buf.value = tmp);
/* see if can build a name */
- if (gss_import_name (&smn,&buf,GSS_C_NT_HOSTBASED_SERVICE,&name) !=
- GSS_S_COMPLETE) return NIL;
+ /*if (gss_import_name (&smn,&buf,GSS_C_NT_HOSTBASED_SERVICE,&name) !=
+ GSS_S_COMPLETE) return NIL;*/
/* remove server method if no keytab */
if (!kerberos_server_valid ()) auth_gss.server = NIL;
- gss_release_name (&smn,&name);/* finished with name */
+ /*gss_release_name (&smn,&name);*//* finished with name */
return LONGT;
}
its interesting that commenting out gss_import_name ()/gss_release_name() fixes it. in case someone feels courageous enough to play with a debugger, i believe this information should be sufficient to finally track down the issue.
@oldsharp : i found an issue, which i just pushed a fix for ( 3b5f410 ). would you mind testing latest git with an unpatched alpine to find out if it fixes the issue ?
@rofl0r I tested 3b5f410 with un-patched alpine; still hit exactly the same failure as before.
sigh, thanks. another thing we could try is increasing the stack size even more (where it says 64*1024
in that commit, you could for instance test 256*1024
instead), even though it doesn't seem too likely that it will fix the issue.
rofl0r notifications@github.com wrote:
another thing we could try is increasing the stack size even more (where it says 641024 in that commit, you could for instance test 2561024 instead)
Tested 256*1024 (and even larger), but seem not fix the issue.
Ray
ok, thank you. an option to get this issue fixed would be that someone gives me ssh access to a mac (since i dont own one), so i can try to debug it.
i fixed a segfault issue, maybe it was related: https://github.com/rofl0r/proxychains-ng/commit/cc7bc891ffd9ed1ebcb61d61f36ed02a0e401504
rofl0r wrote:
i fixed a segfault issue, maybe it was related: https://github.com/rofl0r/proxychains-ng/commit/cc7bc891ffd9ed1ebcb61d61f36ed02a0e401504
Hit build error on macOS with cc7bc89:
$ make printf '#define VERSION "%s"\n' "$(sh tools/version.sh)" > src/version.h cc -DSUPER_SECURE -Ds6_addr16=u6_addr.u6_addr16 -Ds6_addr32=u6_addr.u6_addr32 -Wall -O0 -g -std=c99 -D_GNU_SOURCE -pipe -DIS_MAC=1 -DLIB_DIR=\"/usr/local/lib\" -DSYSCONFDIR=\"/usr/local/etc\" -DDLL_NAME=\"libproxychains4.dylib\" -fPIC -c -o src/version.o src/version.c cc -DSUPER_SECURE -Ds6_addr16=u6_addr.u6_addr16 -Ds6_addr32=u6_addr.u6_addr32 -Wall -O0 -g -std=c99 -D_GNU_SOURCE -pipe -DIS_MAC=1 -DLIB_DIR=\"/usr/local/lib\" -DSYSCONFDIR=\"/usr/local/etc\" -DDLL_NAME=\"libproxychains4.dylib\" -fPIC -c -o src/allocator_thread.o src/allocator_thread.c src/allocator_thread.c:322:9: warning: 'PTHREAD_STACK_MIN' macro redefined [-Wmacro-redefined]
^
/usr/include/limits.h:117:9: note: previous definition is here
^
src/allocator_thread.c:329:50: error: use of undeclared identifier 'MAP_ANON' void *shm = mmap(0, 4096, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED, -1, 0); ^ 1 warning and 1 error generated. make: *** [src/allocator_thread.o] Error 1
Ray
thanks, this should be fixed with d28f4df
OS X version:
El Capitan (10.11.3)
proxychains version:proxychains-ng 4.11
(via Homebrew) alpine version:Alpine 2.20 (OSX 67 2015-01-07)
(via Homebrew)I used to ran
proxychains4 alpine
on my GNU/Linux desktop and it worked well.When I tried to run the same cmd on my Mac, I got a Segmentation Fault:
Tried it in
lldb
and got result as below:And the corefile:
I'm not sure if those msg is enough to address the problem. Should I recompile both proxychains and alpine from src with debug flag enabled and produce another corefile then?