Re: X server crash when running texworks
On 3/31/2012 11:26 AM, Ken Brown wrote: On 3/31/2012 6:28 AM, Jon TURNEY wrote: On 30/03/2012 12:36, Jon TURNEY wrote: On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll #12 0x0043a350 in ?? () #13 0x0047b8c5 in ?? () #14 0x6d46e733 in cygQtCore-4!_ZN11QMetaObject8activateEP7QObjectPKS_iPPv () from /usr/bin/cygQtCore-4.dll #15 0x6bc8b99b in cygQtGui-4!_ZN7QAction9triggeredEb () from /usr/bin/cygQtGui-4.dll #16 0x6bc8bb9a in cygQtGui-4!_ZN7QAction8activateENS_11ActionEventE () from /usr/bin/cygQtGui-4.dll #17 0x6c08dd06 in cygQtGui-4!_ZN11QToolButton14nextCheckStateEv () from /usr/bin/cygQtGui-4.dll #18 0x6bfe0185 in cygQtGui-4!_ZN22QAbstractButtonPrivate5clickEv () from /usr/bin/cygQtGui-4.dll #19 0x6bfe0426 in cygQtGui-4!_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #20 0x6c08ddac in cygQtGui-4!_ZN11QToolButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #21 0x6bcd8769 in cygQtGui-4!_ZN7QWidget5eventEP6QEvent () from /usr/bin/cygQtGui-4.dll #22 0x6bc90fec in cygQtGui-4!_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #23 0x6bc95e45 in cygQtGui-4!_ZN12QApplication6notifyEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #24 0x6d45cefd in cygQtCore-4!_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent () from /usr/bin/cygQtCore-4.dll #25 0x6bc91d98 in cygQtGui-4!_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb () from /usr/bin/cygQtGui-4.dll #26 0x6bd007ed in cygQtGui-4!_ZN9QETWidget19translateMouseEventEPK7_XEvent () from /usr/bin/cygQtGui-4.dll #27 0x6bcff421 in cygQtGui-4!_ZN12QApplication15x11ProcessEventEP7_XEvent () from /usr/bin/cygQtGui-4.dll #28 0x6bd21f82 in cygQtGui-4!_ZN23QGuiEventDispatcherGlibC2EP7QObject () from /usr/bin/cygQtGui-4.dll #29 0x5efecb08 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #30 0x5efed208 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #31 0x5efed3cf in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll #32 0x6d480671 in cygQtCore-4!_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtCore-4.dll #33 0x6bd21cb7 in cygQtGui-4!_ZN23QGuiEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtGui-4.dll #34 0x6d45c587 in
Re: X server crash when running texworks
On Mon, Apr 2, 2012 at 6:04 AM, Ken Brown wrote: This was apparently a cygwin1.dll problem. I've installed the 2012-04-01 cygwin1.dll snapshot, and XWin.20120329-git-6d4583d53c249549.exe starts again. I've resumed testing texworks. I had a similar experience. I could not get xterms to start using the 03/30 snapshot. I tried the 04/01 snapshot this morning and all seems back to normal. Also using the experimental 1.12 X server. -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 4/2/2012 8:04 AM, Ken Brown wrote: On 3/31/2012 11:26 AM, Ken Brown wrote: On 3/31/2012 6:28 AM, Jon TURNEY wrote: On 30/03/2012 12:36, Jon TURNEY wrote: On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll #12 0x0043a350 in ?? () #13 0x0047b8c5 in ?? () #14 0x6d46e733 in cygQtCore-4!_ZN11QMetaObject8activateEP7QObjectPKS_iPPv () from /usr/bin/cygQtCore-4.dll #15 0x6bc8b99b in cygQtGui-4!_ZN7QAction9triggeredEb () from /usr/bin/cygQtGui-4.dll #16 0x6bc8bb9a in cygQtGui-4!_ZN7QAction8activateENS_11ActionEventE () from /usr/bin/cygQtGui-4.dll #17 0x6c08dd06 in cygQtGui-4!_ZN11QToolButton14nextCheckStateEv () from /usr/bin/cygQtGui-4.dll #18 0x6bfe0185 in cygQtGui-4!_ZN22QAbstractButtonPrivate5clickEv () from /usr/bin/cygQtGui-4.dll #19 0x6bfe0426 in cygQtGui-4!_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #20 0x6c08ddac in cygQtGui-4!_ZN11QToolButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #21 0x6bcd8769 in cygQtGui-4!_ZN7QWidget5eventEP6QEvent () from /usr/bin/cygQtGui-4.dll #22 0x6bc90fec in cygQtGui-4!_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #23 0x6bc95e45 in cygQtGui-4!_ZN12QApplication6notifyEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #24 0x6d45cefd in cygQtCore-4!_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent () from /usr/bin/cygQtCore-4.dll #25 0x6bc91d98 in cygQtGui-4!_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb () from /usr/bin/cygQtGui-4.dll #26 0x6bd007ed in cygQtGui-4!_ZN9QETWidget19translateMouseEventEPK7_XEvent () from /usr/bin/cygQtGui-4.dll #27 0x6bcff421 in cygQtGui-4!_ZN12QApplication15x11ProcessEventEP7_XEvent () from /usr/bin/cygQtGui-4.dll #28 0x6bd21f82 in cygQtGui-4!_ZN23QGuiEventDispatcherGlibC2EP7QObject () from /usr/bin/cygQtGui-4.dll #29 0x5efecb08 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #30 0x5efed208 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #31 0x5efed3cf in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll #32 0x6d480671 in cygQtCore-4!_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtCore-4.dll #33 0x6bd21cb7 in cygQtGui-4!_ZN23QGuiEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from
Re: X server crash when running texworks
On 2012-04-02 16:14, Ken Brown wrote: Much earlier in the thread I mentioned a warning QFileSystemWatcher: failed to add paths: /home/kbrown. I've looked at the QtCore sources, and that warning is generated by the function QFileSystemWatcher::addPaths, in corelib/io/qfilesystemwatcher.cpp. If I'm understanding the code correctly, that function tries to use a native (system-specific) FileSystemWatcherEngine if possible. The function QFileSystemWatcherPrivate::createNativeEngine in the same file creates native engines on Windows, Linux, FreeBSD, Mac OS, and Symbian, but not on Cygwin. Correct, as the Windows backend won't work OOTB with *NIX filesystem, and we don't support any of the other native backends. I don't know if it's worth pursuing this, but the failure of FileSystemWatcher could conceivably be the problem here. Do you know enough about Qt to have any ideas about how to proceed? Or Yaakov? The only plausible solutions would be to either: * implement inotify[1] in Cygwin on top of Windows' Directory Change Notification APIs[2] (which would benefit a number of packages); * OR implement a FAM/Gamin-based QFileSystemWatcher backend. Yaakov [1] http://man7.org/linux/man-pages/man7/inotify.7.html [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365261%28v=vs.85%29.aspx -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On Sat, Mar 31, 2012 at 9:26 AM, Ken Brown wrote: I wanted to do some further tests, but I thought I should install the latest Cygwin snapshot (2012-03-30) first. With that Cygwin snapshot, the XWin snapshot of 20120329 won't start. It's not quite right here either. Xwin starts up OK, but I can't get an xterm going from the menu (stack dump). But if I open a CMD window and type xterm -display localhost:0 then the xterm starts up OK. - Jim -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 01/04/2012 07:07, Jim Reisert AD1C wrote: On Sat, Mar 31, 2012 at 9:26 AM, Ken Brown wrote: I wanted to do some further tests, but I thought I should install the latest Cygwin snapshot (2012-03-30) first. With that Cygwin snapshot, the XWin snapshot of 20120329 won't start. It's not quite right here either. Xwin starts up OK, but I can't get an xterm going from the menu (stack dump). But if I open a CMD window and type xterm -display localhost:0 then the xterm starts up OK. If the cygwin 1.7.12 snapshot breaks the package XWin, you probably want to report that in the 1.7.12 snapshot call for testing thread, so the people who can fix problems with that will notice. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 31/03/2012 11:28, Jon TURNEY wrote: On 30/03/2012 12:36, Jon TURNEY wrote: For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll I'm not sure how the X server changes could directly cause that to happen. I can reproduce that same problem with the same backtrace with X server 1.11.4-5, so I don't think this can be called a regression in 1.12.0-1. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 30/03/2012 12:36, Jon TURNEY wrote: On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll #12 0x0043a350 in ?? () #13 0x0047b8c5 in ?? () #14 0x6d46e733 in cygQtCore-4!_ZN11QMetaObject8activateEP7QObjectPKS_iPPv () from /usr/bin/cygQtCore-4.dll #15 0x6bc8b99b in cygQtGui-4!_ZN7QAction9triggeredEb () from /usr/bin/cygQtGui-4.dll #16 0x6bc8bb9a in cygQtGui-4!_ZN7QAction8activateENS_11ActionEventE () from /usr/bin/cygQtGui-4.dll #17 0x6c08dd06 in cygQtGui-4!_ZN11QToolButton14nextCheckStateEv () from /usr/bin/cygQtGui-4.dll #18 0x6bfe0185 in cygQtGui-4!_ZN22QAbstractButtonPrivate5clickEv () from /usr/bin/cygQtGui-4.dll #19 0x6bfe0426 in cygQtGui-4!_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #20 0x6c08ddac in cygQtGui-4!_ZN11QToolButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #21 0x6bcd8769 in cygQtGui-4!_ZN7QWidget5eventEP6QEvent () from /usr/bin/cygQtGui-4.dll #22 0x6bc90fec in cygQtGui-4!_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #23 0x6bc95e45 in cygQtGui-4!_ZN12QApplication6notifyEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #24 0x6d45cefd in cygQtCore-4!_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent () from /usr/bin/cygQtCore-4.dll #25 0x6bc91d98 in cygQtGui-4!_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb () from /usr/bin/cygQtGui-4.dll #26 0x6bd007ed in cygQtGui-4!_ZN9QETWidget19translateMouseEventEPK7_XEvent () from /usr/bin/cygQtGui-4.dll #27 0x6bcff421 in cygQtGui-4!_ZN12QApplication15x11ProcessEventEP7_XEvent () from /usr/bin/cygQtGui-4.dll #28 0x6bd21f82 in cygQtGui-4!_ZN23QGuiEventDispatcherGlibC2EP7QObject () from /usr/bin/cygQtGui-4.dll #29 0x5efecb08 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #30 0x5efed208 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #31 0x5efed3cf in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll #32 0x6d480671 in cygQtCore-4!_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtCore-4.dll #33 0x6bd21cb7 in cygQtGui-4!_ZN23QGuiEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtGui-4.dll #34 0x6d45c587 in
Re: X server crash when running texworks
On 3/31/2012 6:28 AM, Jon TURNEY wrote: On 30/03/2012 12:36, Jon TURNEY wrote: On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll #12 0x0043a350 in ?? () #13 0x0047b8c5 in ?? () #14 0x6d46e733 in cygQtCore-4!_ZN11QMetaObject8activateEP7QObjectPKS_iPPv () from /usr/bin/cygQtCore-4.dll #15 0x6bc8b99b in cygQtGui-4!_ZN7QAction9triggeredEb () from /usr/bin/cygQtGui-4.dll #16 0x6bc8bb9a in cygQtGui-4!_ZN7QAction8activateENS_11ActionEventE () from /usr/bin/cygQtGui-4.dll #17 0x6c08dd06 in cygQtGui-4!_ZN11QToolButton14nextCheckStateEv () from /usr/bin/cygQtGui-4.dll #18 0x6bfe0185 in cygQtGui-4!_ZN22QAbstractButtonPrivate5clickEv () from /usr/bin/cygQtGui-4.dll #19 0x6bfe0426 in cygQtGui-4!_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #20 0x6c08ddac in cygQtGui-4!_ZN11QToolButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #21 0x6bcd8769 in cygQtGui-4!_ZN7QWidget5eventEP6QEvent () from /usr/bin/cygQtGui-4.dll #22 0x6bc90fec in cygQtGui-4!_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #23 0x6bc95e45 in cygQtGui-4!_ZN12QApplication6notifyEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #24 0x6d45cefd in cygQtCore-4!_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent () from /usr/bin/cygQtCore-4.dll #25 0x6bc91d98 in cygQtGui-4!_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb () from /usr/bin/cygQtGui-4.dll #26 0x6bd007ed in cygQtGui-4!_ZN9QETWidget19translateMouseEventEPK7_XEvent () from /usr/bin/cygQtGui-4.dll #27 0x6bcff421 in cygQtGui-4!_ZN12QApplication15x11ProcessEventEP7_XEvent () from /usr/bin/cygQtGui-4.dll #28 0x6bd21f82 in cygQtGui-4!_ZN23QGuiEventDispatcherGlibC2EP7QObject () from /usr/bin/cygQtGui-4.dll #29 0x5efecb08 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #30 0x5efed208 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #31 0x5efed3cf in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll #32 0x6d480671 in cygQtCore-4!_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtCore-4.dll #33 0x6bd21cb7 in cygQtGui-4!_ZN23QGuiEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtGui-4.dll #34 0x6d45c587 in
Re: X server crash when running texworks
On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). I'm not sure how the X server changes could directly cause that to happen. For me, it usually completes running the spawned pdftext, but that reports the error ! I can't find file `test1.tex'. A word about why the icons look so bad: The _NET_WM_ICON icons that texworks has are only provided in 128x128 and 512x512 sizes, which we then have to scale down to 32x32. I'm not sure if these icons aren't too large to be useful anywhere! :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 28/03/2012 13:44, Ken Brown wrote: On 3/28/2012 8:28 AM, Ken Brown wrote: On 3/28/2012 7:16 AM, Jon TURNEY wrote: I'm afraid I can't reproduce your issue, but looking at the backtrace and the somewhat intermittent nature of the fault, I think perhaps this crash is caused by a race condition which exists in the conversion of the window icon from an X property to a Windows icon. I've uploaded a snapshot with some fixes for that at [1], perhaps you could try that out and see if it helps? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120328-git-ab32650607c59327.exe.bz2 Yes, that seems to fix it. I just started texworks and compiled 6 or 7 tex documents without a crash. I've never been able to do more than 1 or 2 before. Good. I spoke too soon. I closed texworks and was doing other things (not even involving X to my knowledge), and the X server just crashed. I'm attaching XWin.0.log. Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. [1] ftp://cygwin.com/pub/cygwinx/XWin.20120329-git-6d4583d53c249549.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 3/29/2012 8:14 AM, Jon TURNEY wrote: On 28/03/2012 13:44, Ken Brown wrote: On 3/28/2012 8:28 AM, Ken Brown wrote: On 3/28/2012 7:16 AM, Jon TURNEY wrote: I'm afraid I can't reproduce your issue, but looking at the backtrace and the somewhat intermittent nature of the fault, I think perhaps this crash is caused by a race condition which exists in the conversion of the window icon from an X property to a Windows icon. I've uploaded a snapshot with some fixes for that at [1], perhaps you could try that out and see if it helps? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120328-git-ab32650607c59327.exe.bz2 Yes, that seems to fix it. I just started texworks and compiled 6 or 7 tex documents without a crash. I've never been able to do more than 1 or 2 before. Good. I spoke too soon. I closed texworks and was doing other things (not even involving X to my knowledge), and the X server just crashed. I'm attaching XWin.0.log. Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). After I kill texworks, `ps' shows a dbus-daemon process and a dbus-launch process that weren't there before I started texworks, but maybe that's to be expected. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 2012-03-29 14:59, Ken Brown wrote: OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. fork() errors? Are there any messages on the console? In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). After I kill texworks, `ps' shows a dbus-daemon process and a dbus-launch process that weren't there before I started texworks, but maybe that's to be expected. texworks uses QtDBus, so it needs a DBus session bus. If one isn't present (which nowadays you need for just about anything), it will start its own instance. If you are using multiwindow with startxwin, I strongly recommend adding the following to the beginning of your ~/.startxwinrc: eval `dbus-launch --sh-syntax` Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 3/29/2012 4:20 PM, Yaakov (Cygwin/X) wrote: On 2012-03-29 14:59, Ken Brown wrote: OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. fork() errors? Are there any messages on the console? Here's what I see in the xterm window from which I started texworks: $ QFileSystemWatcher: failed to add paths: /home/kbrown pdfTeX 3.1415926-2.3-1.40.12 (TeX Live 2011) kpathsea version 6.0.1 Copyright 2011 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.4.8; using libpng 1.4.8 Compiled with zlib 1.2.5; using zlib 1.2.5 Compiled with poppler version 0.18.2 Everything looks normal except for the QFileSystemWatcher message. When I do `ps' at this point, it shows a defunct pdftex process. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). After I kill texworks, `ps' shows a dbus-daemon process and a dbus-launch process that weren't there before I started texworks, but maybe that's to be expected. texworks uses QtDBus, so it needs a DBus session bus. If one isn't present (which nowadays you need for just about anything), it will start its own instance. If you are using multiwindow with startxwin, I strongly recommend adding the following to the beginning of your ~/.startxwinrc: eval `dbus-launch --sh-syntax` I normally do this, but this time I had started the X server without my .startxwinrc for testing purposes. I've just restarted it in my normal way. I still get the texworks hang, but there are no longer extra dbus processes. So that 's not the issue. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 2012-03-24 14:47, Ken Brown wrote:
1. Install texworks-0.4.3-1 from Cygwin Ports.
2. Create two tex files in your home directory, say test1.tex and
test2.tex. I don't know if the contents matter, but in my case both
files contain the following:
\documentclass{article}
\begin{document}
Hello
\end{document}
3. Start the X server by using the Start Menu shortcut.
4. Start texworks by typing texworks in an xterm window.
5. Click on the Open icon to open one of the tex files. Then do the
same to open the second.
At this point the X server crashes and gives the message Caught signal
11 (segmentation fault). Server aborting.
Before the crash I get the following warning in the xterm window when I
open a file:
QFileSystemWatcher: failed to add paths: /home/kbrown
I don't know if this is significant.
Confirmed, cause unknown. It might be a couple of weeks before I can
get back to this.
Yaakov
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 26/03/2012 21:32, Ken Brown wrote: On 3/26/2012 4:06 PM, Jon TURNEY wrote: On 26/03/2012 20:47, Ken Brown wrote: On 3/24/2012 3:47 PM, Ken Brown wrote: One further detail for anyone trying to reproduce this: I just tried it on a second computer, and my recipe didn't immediately produce the crash. But I simply started trying to use texworks (loading and compiling various tex documents), and the X server crashed within a few minutes. Thanks very much for the detailed report. On the off chance this is a known issue, would you mind downloading the X server symbols and getting a backtrace using the instruction on [1], before I try to reproduce it. OK, the backtrace is attached. Thanks very much. I'm afraid I can't reproduce your issue, but looking at the backtrace and the somewhat intermittent nature of the fault, I think perhaps this crash is caused by a race condition which exists in the conversion of the window icon from an X property to a Windows icon. I've uploaded a snapshot with some fixes for that at [1], perhaps you could try that out and see if it helps? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120328-git-ab32650607c59327.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 3/28/2012 7:16 AM, Jon TURNEY wrote: On 26/03/2012 21:32, Ken Brown wrote: On 3/26/2012 4:06 PM, Jon TURNEY wrote: On 26/03/2012 20:47, Ken Brown wrote: On 3/24/2012 3:47 PM, Ken Brown wrote: One further detail for anyone trying to reproduce this: I just tried it on a second computer, and my recipe didn't immediately produce the crash. But I simply started trying to use texworks (loading and compiling various tex documents), and the X server crashed within a few minutes. Thanks very much for the detailed report. On the off chance this is a known issue, would you mind downloading the X server symbols and getting a backtrace using the instruction on [1], before I try to reproduce it. OK, the backtrace is attached. Thanks very much. I'm afraid I can't reproduce your issue, but looking at the backtrace and the somewhat intermittent nature of the fault, I think perhaps this crash is caused by a race condition which exists in the conversion of the window icon from an X property to a Windows icon. I've uploaded a snapshot with some fixes for that at [1], perhaps you could try that out and see if it helps? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120328-git-ab32650607c59327.exe.bz2 Yes, that seems to fix it. I just started texworks and compiled 6 or 7 tex documents without a crash. I've never been able to do more than 1 or 2 before. Thanks! Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 3/24/2012 3:47 PM, Ken Brown wrote:
To reproduce:
1. Install texworks-0.4.3-1 from Cygwin Ports.
2. Create two tex files in your home directory, say test1.tex and
test2.tex. I don't know if the contents matter, but in my case both
files contain the following:
\documentclass{article}
\begin{document}
Hello
\end{document}
3. Start the X server by using the Start Menu shortcut.
4. Start texworks by typing texworks in an xterm window.
5. Click on the Open icon to open one of the tex files. Then do the
same to open the second.
At this point the X server crashes and gives the message Caught signal
11 (segmentation fault). Server aborting.
Before the crash I get the following warning in the xterm window when I
open a file:
QFileSystemWatcher: failed to add paths: /home/kbrown
I don't know if this is significant.su
I'm attaching cygcheck output and XWin.0.log.
Ken
P.S. I'm currently using the test version of xorg-server (1.12.0-1), but
I can reproduce the crash with 1.11.4-5 also. Also, I'm currently
testing the latest Cygwin snapshot. I just tried reverting to 1.7.11,
and the X server still crashed, but not just from opening two files. I
had to open and compile several tex documents before it happened.
One further detail for anyone trying to reproduce this: I just tried it
on a second computer, and my recipe didn't immediately produce the
crash. But I simply started trying to use texworks (loading and
compiling various tex documents), and the X server crashed within a few
minutes.
Ken
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 26/03/2012 20:47, Ken Brown wrote:
On 3/24/2012 3:47 PM, Ken Brown wrote:
To reproduce:
1. Install texworks-0.4.3-1 from Cygwin Ports.
2. Create two tex files in your home directory, say test1.tex and
test2.tex. I don't know if the contents matter, but in my case both
files contain the following:
\documentclass{article}
\begin{document}
Hello
\end{document}
3. Start the X server by using the Start Menu shortcut.
4. Start texworks by typing texworks in an xterm window.
5. Click on the Open icon to open one of the tex files. Then do the
same to open the second.
At this point the X server crashes and gives the message Caught signal
11 (segmentation fault). Server aborting.
Before the crash I get the following warning in the xterm window when I
open a file:
QFileSystemWatcher: failed to add paths: /home/kbrown
I don't know if this is significant.su
I'm attaching cygcheck output and XWin.0.log.
Ken
P.S. I'm currently using the test version of xorg-server (1.12.0-1), but
I can reproduce the crash with 1.11.4-5 also. Also, I'm currently
testing the latest Cygwin snapshot. I just tried reverting to 1.7.11,
and the X server still crashed, but not just from opening two files. I
had to open and compile several tex documents before it happened.
One further detail for anyone trying to reproduce this: I just tried it on a
second computer, and my recipe didn't immediately produce the crash. But I
simply started trying to use texworks (loading and compiling various tex
documents), and the X server crashed within a few minutes.
Thanks very much for the detailed report.
On the off chance this is a known issue, would you mind downloading the X
server symbols and getting a backtrace using the instruction on [1], before I
try to reproduce it.
[1] http://x.cygwin.com/devel/backtrace.html
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 3/26/2012 4:06 PM, Jon TURNEY wrote:
On 26/03/2012 20:47, Ken Brown wrote:
On 3/24/2012 3:47 PM, Ken Brown wrote:
To reproduce:
1. Install texworks-0.4.3-1 from Cygwin Ports.
2. Create two tex files in your home directory, say test1.tex and
test2.tex. I don't know if the contents matter, but in my case both
files contain the following:
\documentclass{article}
\begin{document}
Hello
\end{document}
3. Start the X server by using the Start Menu shortcut.
4. Start texworks by typing texworks in an xterm window.
5. Click on the Open icon to open one of the tex files. Then do the
same to open the second.
At this point the X server crashes and gives the message Caught signal
11 (segmentation fault). Server aborting.
Before the crash I get the following warning in the xterm window when I
open a file:
QFileSystemWatcher: failed to add paths: /home/kbrown
I don't know if this is significant.su
I'm attaching cygcheck output and XWin.0.log.
Ken
P.S. I'm currently using the test version of xorg-server (1.12.0-1), but
I can reproduce the crash with 1.11.4-5 also. Also, I'm currently
testing the latest Cygwin snapshot. I just tried reverting to 1.7.11,
and the X server still crashed, but not just from opening two files. I
had to open and compile several tex documents before it happened.
One further detail for anyone trying to reproduce this: I just tried it on a
second computer, and my recipe didn't immediately produce the crash. But I
simply started trying to use texworks (loading and compiling various tex
documents), and the X server crashed within a few minutes.
Thanks very much for the detailed report.
On the off chance this is a known issue, would you mind downloading the X
server symbols and getting a backtrace using the instruction on [1], before I
try to reproduce it.
OK, the backtrace is attached.
Ken
$ gdb --pid=5152
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
[...]
Reading symbols from /usr/bin/XWin.exe...Reading symbols from
/usr/lib/debug/usr/bin/XWin.dbg...
warning: section .gnu_debuglink not found in /usr/lib/debug/usr/bin/XWin.dbg
done.
done.
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6040.0x1ac]
0x004097c2 in NetWMToWinIconAlpha (icon=0xfed20010)
at
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:295
295
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:
No such file or directory.
in
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c
(gdb) bt full
#0 0x004097c2 in NetWMToWinIconAlpha (icon=0xfed20010)
at
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:295
hdc = optimized out
ii = {fIcon = 1, xHotspot = 0, yHotspot = 0, hbmMask = 0xf050f17,
hbmColor = 0x93051250}
bmh = {bV4Size = 108, bV4Width = 512, bV4Height = -512, bV4Planes = 1,
bV4BitCount = 32, bV4V4Compression = 3, bV4SizeImage = 0,
bV4XPelsPerMeter = 0, bV4YPelsPerMeter = 0, bV4ClrUsed = 0,
bV4ClrImportant = 0, bV4RedMask = 16711680, bV4GreenMask = 65280,
bV4BlueMask = 255, bV4AlphaMask = 4278190080, bV4CSType = 0,
bV4Endpoints = {ciexyzRed = {ciexyzX = 0, ciexyzY = 0, ciexyzZ = 0},
ciexyzGreen = {ciexyzX = 0, ciexyzY = 0, ciexyzZ = 0},
ciexyzBlue = {ciexyzX = 0, ciexyzY = 0, ciexyzZ = 0}},
bV4GammaRed = 0, bV4GammaGreen = 0, bV4GammaBlue = 0}
width = optimized out
height = 512
pixels = 0xfed20018
result = 0x2610b75
DIB_pixels = 0x4ff
#1 NetWMToWinIcon (bpp=optimized out, icon=0xfed20010)
at
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:369
hasIconAlphaChannel = 1
versionChecked = 1 '\001'
#2 0x0040a085 in winXIconToHICON (pWin=0x805399d8, iconSize=32)
at
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:449
mask = optimized out
image = optimized out
imageMask = optimized out
dst = optimized out
src = optimized out
iconPtr = optimized out
maskPtr = optimized out
planes = 1
bpp = 32
effBPP = optimized out
i = optimized out
biggest_size = 512
hDC = optimized out
ii = {fIcon = 1969585604, xHotspot = 196958, yHotspot = 283154527,
hbmMask = 0x0, hbmColor = 0x0}
hints = {flags = 1969585433, input = 11, initial_state = 11,
icon_pixmap = 0, icon_window = 4292791408, icon_x = 1969578512,
icon_y = -2142004644, icon_mask = 1024, window_group = 4292791464}
hIcon = 0x0
biggest_icon = optimized out
