I'm having trouble with websockets. I think this is caused by new dyld improvements (You can check the improvements via this link.). Where can I find linker flags to disable them?(man page or --help_hidden are not contains these options) Thanks.
libsp.dylib`spd_checkin_socket.cold.1:
0x226af4364 <+0>: adrp x8, 141669
0x226af4368 <+4>: adrp x9, 0
> 0x226af436c <+8>: add x9, x9, #0xa3f ; "Linked against modern SDK, VOIP socket will not wake. Use Local Push Connectivity instead"
0x226af4370 <+12>: str x9, [x8, #0x400]
-> 0x226af4374 <+16>: brk #0x1
Related
I have an Android Application that uses the NDK. In my C++ code I have a call to std::use_facet(). On its own my application runs fine however when I add the ACRCloud SDK I get a crash right when I launch my app:
Build fingerprint: 'google/taimen/taimen:9/PPR2.180905.005/4928864:user/release-keys'
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: Revision: 'rev_10'
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: ABI: 'arm'
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: pid: 2915, tid: 2915, name: .app >>> com.mycompany.android.app <<<
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: Cause: null pointer dereference
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: r0 00000000 r1 00000043 r2 d5b21700 r3 00000000
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: r4 ffd1a974 r5 ebd856ac r6 ebd856ac r7 d551c3a4
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: r8 d3acfae8 r9 f45842c0 r10 00000143 r11 ffd1a9b4
2018-10-17 14:48:36.357 2938-2938/? A/DEBUG: ip 00000000 sp ffd1a948 lr d473ae40 pc d473ae54
2018-10-17 14:48:36.550 2938-2938/? A/DEBUG: backtrace:
2018-10-17 14:48:36.550 2938-2938/? A/DEBUG: #00 pc 03e2fe54 /data/app/com.mycompany.android.app-APqEWGjyWJxWwxYs8NNiHA==/lib/arm/libMyApp.so (std::ctype<char> const& std::use_facet<std::ctype<char>>(std::locale const&)+40)
2018-10-17 14:48:36.550 2938-2938/? A/DEBUG: #01 pc 023ee45c /data/app/com.mycompany.android.app-APqEWGjyWJxWwxYs8NNiHA==/lib/arm/libMyApp.so (_ZNSt8__detail9_CompilerISt12regex_traitsIcEEC1EPKcS5_RKS2_NSt15regex_constants18syntax_option_typeE+232)
2018-10-17 14:48:36.550 2938-2938/? A/DEBUG: #02 pc 023eb19c /data/app/com.mycompany.android.app-APqEWGjyWJxWwxYs8NNiHA==/lib/arm/libMyApp.so (_ZNSt8__detail13__compile_nfaISt12regex_traitsIcEEESt10shared_ptrINS_4_NFAIT_EEEPKNS5_9char_typeESA_RKS5_NSt15regex_constants18syntax_option_typeE+80)
2018-10-17 14:48:36.550 2938-2938/? A/DEBUG: #03 pc 023e8d28 /data/app/com.mycompany.android.app-APqEWGjyWJxWwxYs8NNiHA==/lib/arm/libMyApp.so (_ZNSt11basic_regexIcSt12regex_traitsIcEEC2IPKcEET_S6_NSt15regex_constants18syntax_option_typeE+240)
The crash shows up in my native library but I believe it is something to do with the ACRCloud library being in there that is causing this.
Note that at the point of the crash there is no code running yet that instantiates any of the ACRCloud SDK.
My gut feeling is that ACRCloud is also using the same method call somewhere, std::use_facet(), and during compilation the symbols from ACRCloud are being brought in instead of mine and that is somehow causing a conflict.
Perhaps someone at ACRCloud can chime in.
This crash is caused by “/lib/arm/libMyApp.so”. It may be your own library. ACRCloud SDK does not contain this library.
So turns out my build setup was incorrect. I'm using Bazel to build everything and I was referencing the ACRCloud library using a cc_library rule rather than what it should have been: filegroup.
I think when I used cc_library rule something was being modified during compilation and that led to my error; whereas, if I import it via filegroup the artifact will just be brought in without being touched in any way.
I am trying to debug an access violation in my program using WinDbg. The debugger catches the access violation correctly:
(2604.1e74): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0808e7fb ebx=007b39f8 ecx=000116e7 edx=7ead8618 esi=00000000 edi=00000000
eip=006ed845 esp=0818ff24 ebp=0818ff30 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
image00400000!t_control.is_focused+0x15:
006ed845 8b8051070000 mov eax,dword ptr [eax+751h] ds:002b:0808ef4c=????????
I want to “skip” the access violation so that I can continue debugging (e.g. step out of the faulting function to inspect the data structures of the caller). So I change eax so that it points to a readable memory, for instance the current code, so I do:
0:025> r eax=eip
This seems to work fine, as the following verification seems to indicate:
0:025> r
eax=006ed845 ebx=007b39f8 ecx=000116e7 edx=7ead8618 esi=00000000 edi=00000000
eip=006ed845 esp=0818ff24 ebp=0818ff30 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
image00400000!t_control.is_focused+0x15:
006ed845 8b8051070000 mov eax,dword ptr [eax+751h] ds:002b:006edf96=012c0000
However, as soon as I try to step (or continue) the program, it faults again in exactly the same way, as if the register did not change at all:
0:025> p
(2604.1e74): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0808e7fb ebx=007b39f8 ecx=000116e7 edx=7ead8618 esi=00000000 edi=00000000
eip=006ed845 esp=0818ff24 ebp=0818ff30 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
image00400000!t_control.is_focused+0x15:
006ed845 8b8051070000 mov eax,dword ptr [eax+751h] ds:002b:0808ef4c=????????
What am I doing wrong? (The debuggee is a 32-bit program written in Delphi, running under WinDbg X86, on 64-bit Windows 7. Neither the debuggee, nor WinDbg run elevated.)
You have to use
gh (Go with Exception Handled)
to continue after you have manipulated your eax register
(2f14.1950): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=7efde000 ecx=94a31deb edx=0f709488 esi=0033f99c edi=0033fa80
eip=000d1a3f esp=0033f99c ebp=0033fa80 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
SimpleCrash!wmain+0x3f:
000d1a3f 8b08 mov ecx,dword ptr [eax] ds:002b:00000000=????????
0:000> r #eax=#eip
0:000> gh
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=77882100 edi=778820c0
eip=7779fcc2 esp=0033f9e8 ebp=0033fa04 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!NtTerminateProcess+0x12:
7779fcc2 83c404 add esp,4
Platform: Windows XP;
MingGW with (gcc v.4.7.2)
As stated in the topic, how can I achive this?
Why? I determine a crash of my multi-threaded application on Windowx XP, in case I compile the application with MinGW. According to the backtrace, the application crashes in the "setlocale" function, which is builtin in the "msvcrt.dll".
I've tried to compile my application with Visual Studio 2010 and I determined no such a crash, as the dependency walker revealed, that the "msvcr100.dll" is linked, and maybe contains a more robust version of the "setlocale" function.
Here the backtrace:
ABoostLog.exe caused an Access Violation at location 77c03509 in module msvcrt.dll Reading from location 00000000.
Registers:
eax=00cdfb88 ebx=003d6afc ecx=003d6d24 edx=003d6d24 esi=00000758 edi=00000000
eip=7c91eb94 esp=00cdfb4c ebp=00cdfbb0 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
Call stack:
7C91EB94 ntdll.dll:7C91EB94 KiFastSystemCallRet
7C802532 kernel32.dll:7C802532 WaitForSingleObject
0041E33D WithThread.exe:0041E33D
XXXXXXXXXXXXXXXXXXXXXX
Registers:
eax=77c2f94c ebx=77c2f94c ecx=00000000 edx=77c2f798 esi=77c2f79a edi=ffffffff
eip=77c03509 esp=0022f520 ebp=0022f534 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297
Call stack:
77C03509 msvcrt.dll:77C03509 unguarded_readlc_active_add_func
77C03C1B msvcrt.dll:77C03C1B
unguarded_readlc_active_add_func
77C03C60 msvcrt.dll:77C03C60 setlocale
6FC671D1 libstdc++-6.dll:6FC671D1 std::__timepunct::_M_put
6FC7A63C libstdc++-6.dll:6FC7A63C std::time_put > >::do_put
6FC7A4CA libstdc++-6.dll:6FC7A4CA std::time_put > >::put
004EE047 ABoostLog.exe:004EE047
So my question is, how to trigger MinGW to link against "msvcr100.dll" within the "libstdc++.dll" and "libgcc_s_dw2-1.dll".
I've already adapted my spec-file to:
*libgcc: %{mthreads:-lmingwthrd} -lmingw32 %{shared-libgcc:-lgcc_s} %{!shared-libgcc:-lgcc_eh} -lgcc -lmoldname -lmingwex -lmsvcr100
But this doesn't help, as the mentioned dll is still linked within the dll's stated. Just take a look to the embedded picture:
Thanks so far!
Br
So my question is, how to trigger MinGW to link against "msvcr100.dll"
within the "libstdc++.dll" and "libgcc_s_dw2-1.dll"
Those libs are supplied and built by MinGW, they are not built as part of your own application build. So you would need to first build those two libs yourself from source to get them to link to msvcr100.dll
But what you should really be doing is linking your application statically to these two libs and eliminating the dll dependencies. For example, in your configure.ac you could use:
CFLAGS="$CFLAGS --static -static-libgcc -static-libstdc++"
LDFLAGS="$LDFLAGS --static"
I still doubt that your particular crash is caused by this. Many dlls depend on msvcrt; just expand your WS2_32.dll for example.
By the way, your custom spec should use -lmoldname100
How do I disable debugger breaks in ntdll!KiFastSystemCallRet instruction?
E.g.:
7:022> g
eax=7754dcf9 ebx=006a1be8 ecx=006a0e40 edx=006a0d18 esi=80300002 edi=00000000
eip=77736954 esp=004afe0c ebp=004afe28 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!KiFastSystemCallRet:
77736954 c3 ret
Thanks.
Well, it came out that breaks in
ntdll!LdrpDoDebuggerBreak+0x2b
Are when binaries are loaded. You get more than one of this kind of break when you are debugging a process with the -o option, this means, all child processes will be also attached to the debugger. E.g.:
windbg.exe -o MyExecutable.exe
And breaks in
ntdll!KiFastSystemCallRet
Are when exeptions occur, e.g.:
sxe ld MyBinary.dll
But it could be many kinds of exceptions, for more information look at sx, sxd, sxe, sxi, sxn, sxr, sx- documentation.
I tried running gdb to disassemble the kernel and tried running:
root#debian:/home/jestinjoy# gdb /usr/src/linux-2.6.38.8/vmlinux
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/src/linux-2.6.38.8/vmlinux...done.
(gdb) disass sys_read
Dump of assembler code for function sys_read:
0xc10cacb9 <sys_read+0>: push %ebp
0xc10cacba <sys_read+1>: mov %esp,%ebp
0xc10cacbc <sys_read+3>: push %esi
0xc10cacbd <sys_read+4>: mov $0xfffffff7,%esi
0xc10cacc2 <sys_read+9>: push %ebx
0xc10cacc3 <sys_read+10>: sub $0xc,%esp
0xc10cacc6 <sys_read+13>: mov 0x8(%ebp),%eax
0xc10cacc9 <sys_read+16>: lea -0xc(%ebp),%edx
0xc10caccc <sys_read+19>: call 0xc10cb346 <fget_light>
0xc10cacd1 <sys_read+24>: test %eax,%eax
0xc10cacd3 <sys_read+26>: mov %eax,%ebx
0xc10cacd5 <sys_read+28>: je 0xc10cad10 <sys_read+87>
0xc10cacd7 <sys_read+30>: mov 0x2c(%ebx),%edx
0xc10cacda <sys_read+33>: mov 0x28(%eax),%eax
0xc10cacdd <sys_read+36>: mov 0x10(%ebp),%ecx
0xc10cace0 <sys_read+39>: mov %edx,-0x10(%ebp)
0xc10cace3 <sys_read+42>: mov 0xc(%ebp),%edx
0xc10cace6 <sys_read+45>: mov %eax,-0x14(%ebp)
0xc10cace9 <sys_read+48>: lea -0x14(%ebp),%eax
0xc10cacec <sys_read+51>: push %eax
0xc10caced <sys_read+52>: mov %ebx,%eax
0xc10cacef <sys_read+54>: call 0xc10cab82 <vfs_read>
0xc10cacf4 <sys_read+59>: mov -0x10(%ebp),%edx
0xc10cacf7 <sys_read+62>: mov %eax,%esi
It works fine. But when I tried running
root#debian:/home/jestinjoy# gdb /usr/src/linux-2.6.38.8/vmlinux /proc/kcore
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/src/linux-2.6.38.8/vmlinux...done.
Core was generated by `BOOT_IMAGE=/boot/vmlinuz-2.6.38.8 root=UUID=b61e8ee2-949a-4810-ac56-42564ee005d7'.
#0 0x00000000 in ?? ()
(gdb) disass sys_read
Dump of assembler code for function sys_read:
0xc10cacb9 <sys_read+0>: add %al,(%eax)
0xc10cacbb <sys_read+2>: add %al,(%eax)
0xc10cacbd <sys_read+4>: add %al,(%eax)
0xc10cacbf <sys_read+6>: add %al,(%eax)
0xc10cacc1 <sys_read+8>: add %al,(%eax)
0xc10cacc3 <sys_read+10>: add %al,(%eax)
0xc10cacc5 <sys_read+12>: add %al,(%eax)
0xc10cacc7 <sys_read+14>: add %al,(%eax)
0xc10cacc9 <sys_read+16>: add %al,(%eax)
0xc10caccb <sys_read+18>: add %al,(%eax)
0xc10caccd <sys_read+20>: add %al,(%eax)
0xc10caccf <sys_read+22>: add %al,(%eax)
0xc10cacd1 <sys_read+24>: add %al,(%eax)
0xc10cacd3 <sys_read+26>: add %al,(%eax)
0xc10cacd5 <sys_read+28>: add %al,(%eax)
0xc10cacd7 <sys_read+30>: add %al,(%eax)
It gives weird result. I am running with
CONFIG_DEBUG_INFO=y and with kernel 2.6.38
Disable CONFIG_RELOCATABLE.
One cannot simply debug running kernel with gdb!
Linux kernel comes with two different front ends for debugging (kdb and KGDB) which are somewhat different but fortunately it is possible to switch between them on the fly.
kdb which is not a source level debugger (so not the one you are looking for), can be used on system console on local machine or via serial connection from another machine.
KGDB is a source level debugger but requires two machines to operate - one of them is the debugged subject (aka the target machine where the debugged code is running) and another is the development machine where gdb is running against the vmlinux file (the same file that the target machine is running). And connection between target and development machine is done via serial port...
Now, there's plenty of documentation how all that is set up under kernel's Documentation directory. Just grep for any of these: kdb, kgdboc, ...
What does "grep sys_read /proc/kallsyms" says on your machine? if it is not 0xc10cacb9 then you don't have the same source or configuration of the running kernel, so the address are mismatched
I can't say Ive used GDB to debug the kernel, but I have used crash ( http://people.redhat.com/anderson/crash_whitepaper/ ) which is a wrapper around gdb. I use it most days and it works a treat.