Mail Archives: cygwin/2014/10/14/14:30:44
On 10/14/2014 12:26 PM, Ken Brown wrote:
> On 6/28/2014 7:08 AM, Ken Brown wrote:
>> On 6/27/2014 1:52 PM, Yaakov Selkowitz wrote:
>>> On 2014-06-27 12:11, Ken Brown wrote:
>>>> On 6/25/2014 10:17 PM, Ken Brown wrote:
>>>>> This is a followup to
>>>>> https://cygwin.com/ml/cygwin/2014-06/msg00324.html, from which I
>>>>> extracted the following test case:
>>>>>
>>>>> $ cat gfile-test.c
>>>>> #include <stdio.h>
>>>>> #include <gio/gio.h>
>>>>>
>>>>> void
>>>>> gfile_add_watch (const char *file)
>>>>> {
>>>>> GFile *gfile = g_file_new_for_path (file);
>>>>> GFileMonitor *monitor;
>>>>> GFileMonitorFlags gflags = G_FILE_MONITOR_NONE;
>>>>> monitor = g_file_monitor (gfile, gflags, NULL, NULL);
>>>>> if (! monitor)
>>>>> printf ("Can't watch file %s\n", file);
>>>>> else
>>>>> printf ("Watching file %s\n", file);
>>>>> }
>>>>>
>>>>> int
>>>>> main ()
>>>>> {
>>>>> const char *file = "gfile-test.c";
>>>>> gfile_add_watch (file);
>>>>> }
>>>>>
>>>>> $ gcc -g -O0 -o gfile-test $(pkg-config --cflags gio-2.0) gfile-test.c
>>>>> $(pkg-config --libs gio-2.0)
>>>>>
>>>>> In the 64-bit case, this behaves as expected:
>>>>>
>>>>> $ ./gfile-test.exe
>>>>> Watching file gfile-test.c
>>>>>
>>>>> In the 32-bit case, however, it crashes. Running it under gdb shows
>>>>> that the call to g_file_monitor leads to a SEGV, but I can't tell
>>>>> exactly where; when I try to single step through the Glib code, I
>>>>> eventually hit an assertion violation in gdb. strace shows lots of
>>>>> exceptions, but I can't make much sense out of it otherwise.
>>>>
>>>> I rebuilt glib and gamin without optimization so that I could step
>>>> through the code in gdb. But stepping through the code turned out to be
>>>> unnecessary, because the bug was gone after the rebuilds. I don't know
>>>> if optimization was really the issue or whether just rebuilding with the
>>>> latest tools is what fixed it.
>>>>
>>>> My builds can be obtained from
>>>>
>>>> http://sanibeltranquility.com/cygwin/
>>>>
>>>> if anyone else wants to try to reproduce this without rebuilding the
>>>> packages themselves.
>>>>
>>>> Yaakov, could you take a look?
>>>
>>> Sure. Are you narrow this down to only one of glib or gamin?
>>
>> The culprit is gamin, and optimization *is* relevant. What's strange, though,
>> is that when I rebuild it with optimization, my test case hangs instead of
>> crashing. Summary:
>>
>> - With gamin-0.1.10-14 (and its subpackages), my test case crashes. The outward
>> symptom is that there's no output, but running the test case under gdb shows the
>> SEGV.
>>
>> - If I rebuild gamin without optimization, I don't see any bug. More precisely,
>> I build it using your gamin.cygport with the following line added:
>>
>> CFLAGS+=" -O0 -g3"
>>
>> - If I rebuild gamin with optimization (i.e., just using your gamin.cygport with
>> no changes), my test case hangs.
>
> I made another attempt to debug this, and I found the problem, but I don't know
> how to fix it. First, I have to correct the last assertion I made above about
> my test case hanging; I just didn't wait long enough for it to finish. What
> happens is that there is a retry loop in
> libgamin/gam_api.c:gamin_connect_unix_socket that gives up after 25 seconds. And
> the reason it fails is that /usr/libexec/gam_server.exe has crashed. In fact,
> the latter always crashes on 32-bit Cygwin if it's built with optimization and
> if the directory /tmp/fam-<username> exists before it is run. [And this
> directory will always exist after one run of gam_server.exe.]
>
> The crash occurs in a call to g_free at server/gam_channel.c:525 because the
> pointer 'dir' that is being freed has been clobbered by a call to
> gam_check_not_fat on line 497. Here are some details, based on a build using
> Yaakov's gamin.cygport file with the added line
>
> CFLAGS+=" -O1 -g3"
>
> I've appended at the end of this message a transcript of a gdb session that
> illustrates some of the assertions I'll be making.
>
> At line 447 of server/gam_channel.c, g_strconcat is called to get a pointer to
> the directory name "/tmp/fam-<username>". The value of this pointer is assigned
> to the variable 'dir' at line 473, and in my run it is 0x8005c068. Although
> 'dir' is optimized out, I can see from a disassembly that the pointer is stored
> on the stack at -0x510(%ebp):
>
> 0x004058fc <+266>: call 0x408bf8 <g_strconcat>
> 0x00405901 <+271>: mov %eax,-0x510(%ebp)
>
> And I verified in my gdb session that this stack location does indeed contain
> 0x8005c068. After the call to gam_check_not_fat a little later, that stack
> location contains the value 0x00000104. Then when g_free attempts to free the
> bogus pointer 0x00000104, we get a crash.
>
> I can't tell from the disassembly why the call to gam_check_not_fat clobbers the
> stack. My best guess is that it happens as a result of calls to some Windows
> functions. I hope someone more knowledgeable can take this further and fix it.
I stepped into gam_check_not_fat (which I should have done to begin with) and
narrowed this down further. The stack location in question gets clobbered by
the call to GetVolumeInformation:
(gdb) s
gam_check_not_fat (path=0x8005c068 "/tmp/fam-kbrown")
at /usr/src/debug/gamin-0.1.10-16/server/gam_channel.c:35
35 cygwin_conv_path(CCP_POSIX_TO_WIN_A, path, winpath, MAX_PATH);
(gdb) x/x $ebp-0x510
0x28a6a8: 0x8005c068
(gdb) n
37 pGVPN = GetProcAddress(LoadLibrary("kernel32"), "GetVolumePathNameA");
(gdb) x/x $ebp-0x510
0x28a6a8: 0x8005c068
(gdb) n
38 if (!pGVPN || !(pGVPN)(winpath, root, MAX_PATH))
(gdb) x/x $ebp-0x510
0x28a6a8: 0x8005c068
(gdb) n
52 if (!GetVolumeInformation (root, volname, MAX_PATH, NULL,
(gdb) x/x $ebp-0x510
0x28a6a8: 0x8005c068
(gdb) n
58 if (!strncmp(fsname, "FAT", 3)) /* FAT, FAT32 */
(gdb) x/x $ebp-0x510
0x28a6a8: 0x00000104
Here's the code near the call to GetVolumeInformation, followed by what I think
is the relevant disassembly:
if (!GetVolumeInformation (root, volname, MAX_PATH, NULL,
NULL, NULL, fsname, MAX_PATH))
{
fprintf (stderr, "GetVolumeInformation: %d\n", GetLastError ());
return 0;
}
0x00405b3a <+840>: movl $0x104,0x1c(%esp) <<<<<<<<<<<<<<<<
0x00405b42 <+848>: lea -0x120(%ebp),%eax
0x00405b48 <+854>: mov %eax,0x18(%esp)
0x00405b4c <+858>: movl $0x0,0x14(%esp)
0x00405b54 <+866>: movl $0x0,0x10(%esp)
0x00405b5c <+874>: movl $0x0,0xc(%esp)
0x00405b64 <+882>: movl $0x104,0x8(%esp) <<<<<<<<<<<<<<<<
0x00405b6c <+890>: lea -0x224(%ebp),%eax
0x00405b72 <+896>: mov %eax,0x4(%esp)
0x00405b76 <+900>: lea -0x328(%ebp),%eax
0x00405b7c <+906>: mov %eax,(%esp)
0x00405b7f <+909>: call *0x41248c <----- GetVolumeInformation?
0x00405b85 <+915>: sub $0x20,%esp
0x00405b88 <+918>: test %eax,%eax
0x00405b8a <+920>: jne 0x405bb5 <gam_server_create+963>
0x00405b8c <+922>: call *0x412480 <----- GetLastError?
0x00405b92 <+928>: mov %eax,%esi
0x00405b94 <+930>: call 0x408df0 <__getreent>
0x00405b99 <+935>: mov %esi,0x8(%esp)
0x00405b9d <+939>: movl $0x40c70f,0x4(%esp)
0x00405ba5 <+947>: mov 0xc(%eax),%eax
0x00405ba8 <+950>: mov %eax,(%esp)
0x00405bab <+953>: call 0x408df8 <fprintf>
0x00405bb0 <+958>: jmp 0x406073 <gam_server_create+2177>
Note the two marked movl instructions involving 0x104; I guess one of these is
the culprit, but I don't really know what's going on.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -