Investigating a fork failure

Discussion:

Jon TURNEY

2015-08-24 14:20:07 UTC

I'm not very happy with the assumption that this is SEP, so I did a bit
more investigation into the problem in [1]

Installing "Lavasoft Ad-Aware Web Companion" into a W7 x86_64 VM, I'm
able to reproduce that problem.

Running 'XWin -multiwindow' under WinDbg, with "Debug child processes
also" enabled, a 2nd chance exception occurs in bash, with the following

# Child-SP RetAddr Call Site
00 00000000`0022e2e0 00000000`7755f37a ntdll!KiUserCallbackDispatcher+0x1b
01 00000000`0022e338 00000000`7755f3af USER32!NtUserRegisterWindowMessage+0xa
02 00000000`0022e340 000007fe`fe2f80f2 USER32!RegisterWindowMessageW+0x2b
03 00000000`0022e390 000007fe`fe2f8014 OLEAUT32!_RegisterClipFormat+0xc2
04 00000000`0022e470 000007fe`fe2f33c1 OLEAUT32!_typesDllMain+0x4c
05 00000000`0022e4a0 000007fe`fe2f3356 OLEAUT32!DllMain+0x21
06 00000000`0022e4d0 00000000`7768b108 OLEAUT32!CRT_INIT+0x2af
07 00000000`0022e630 00000000`7767787a ntdll!LdrpRunInitializeRoutines+0x1fe
08 00000000`0022e800 00000000`77677b5e ntdll!LdrpLoadDll+0x231
09 00000000`0022ea10 000007fe`fd439059 ntdll!LdrLoadDll+0x9a
0a 00000000`0022ea80 000007fe`ff917d66 KERNELBASE!LoadLibraryExW+0x22e
0b 00000000`0022eaf0 000007fe`ff915d22 ws2_32!DPROVIDER::Initialize+0x156
0c 00000000`0022f090 000007fe`ff933a90 ws2_32!DCATALOG::LoadProvider+0x7e
0d 00000000`0022f0c0 000007fe`ff920b9b ws2_32!DCATALOG::GetCountedCatalogItemFromCatalogEntryId+0x70
0e 00000000`0022f100 00000001`800ab085 ws2_32!_chkstk+0x362a
0f 00000000`0022f1a0 00000001`8006d8b7 cygwin1!feinitialise+0x33f95
10 00000000`0022f1f0 00000001`800469d0 cygwin1!dlfork+0x3ac7
11 00000000`0022f250 00000001`8004897c cygwin1!setprogname+0x3ed0
12 00000000`0022f2c0 00000001`800c62e9 cygwin1!cygwin_dll_init+0x16ac
13 00000000`0022f320 00000000`7768b108 cygwin1!dll_entry+0x149

I interpret this to mean the situation is something like the following:

LavasoftTcpService64.dll is being loaded as a LSP
LavasoftTcpService64.dll depends on OLEAUT32.dll
OLEAUT32's DllMain calls RegisterWindowMessage
This ends up calling KiUserCallbackDispatcher for a kernel to user-mode
callback.
This accesses a pointer to a callback table at PEB:0x58, which is
unfortunately null.
Sadness follows.

I wonder if anyone has any insight into this or suggestions for further
investigation?

[1] https://cygwin.com/ml/cygwin/2015-08/msg00312.html

Corinna Vinschen

2015-08-24 14:56:12 UTC

Permalink

I'm not very happy with the assumption that this is SEP, so I did a bit more
investigation into the problem in [1]
Installing "Lavasoft Ad-Aware Web Companion" into a W7 x86_64 VM, I'm able
to reproduce that problem.
Running 'XWin -multiwindow' under WinDbg, with "Debug child processes also"
enabled, a 2nd chance exception occurs in bash, with the following call

LavasoftTcpService64.dll is being loaded as a LSP
LavasoftTcpService64.dll depends on OLEAUT32.dll
OLEAUT32's DllMain calls RegisterWindowMessage
This ends up calling KiUserCallbackDispatcher for a kernel to user-mode
callback.
This accesses a pointer to a callback table at PEB:0x58, which is
unfortunately null.
Sadness follows.
I wonder if anyone has any insight into this or suggestions for further
investigation?

The backtrace looks weird. Did you run this with a Cygwin DLL built
without optimization? That might be helpful.

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Jon TURNEY

2015-08-24 18:38:58 UTC

Permalink

Post by Corinna Vinschen
The backtrace looks weird. Did you run this with a Cygwin DLL built
without optimization? That might be helpful.

I ran this using 2.2.0-1

I'm afraid windbg doesn't do a very good job symbolicating the backtrace
through cygwin1.dll, as it only has access to the exported symbols.

Post by Corinna Vinschen
0x00000001800ab085 fhandler_socket::fixup_after_fork(void*) fhandler_socket.cc:842
0x000000018006d8b7 dtable::fixup_after_exec() dtable.cc:895
0x00000001800469d0 child_info_spawn::handle_spawn() dcrt0.cc:688
0x000000018004897c dll_crt0_0() dcrt0.cc:797
0x00000001800c62e9 dll_entry init.cc:85

which hopefully looks a bit more normal.

Corinna Vinschen

2015-08-24 18:54:16 UTC

Permalink

Post by Jon TURNEY

Post by Corinna Vinschen
The backtrace looks weird. Did you run this with a Cygwin DLL built
without optimization? That might be helpful.

I ran this using 2.2.0-1
I'm afraid windbg doesn't do a very good job symbolicating the backtrace
through cygwin1.dll, as it only has access to the exported symbols.

which hopefully looks a bit more normal.

You may want to debug what happens in fdsock. Read the comment in
there, it should help to understand what's going on.

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat