public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
From: Ken <kstmp001@comcast.net> To: cygwin-xfree@cygwin.com Subject: cygwin 1.7.14-2 X-start-menu-icons.sh & xlaunch.sh postinstall produces mkshortcut.exe.stackdump Date: Sat, 05 May 2012 19:47:00 -0000 [thread overview] Message-ID: <4FA583D9.2010100@comcast.net> (raw) [-- Attachment #1: Type: text/plain, Size: 4019 bytes --] Hello, I have come across some odd behavior that I did not experience in cygwin 1.7.11 (I did not try the .12 or .13 releases) that I felt should be reported. And, I could not seem to find any previous mention of this particular issue in the mailing lists. Something appears to be awry with the "X-start-menu-icons.sh" and "xlaunch.sh" postinstall operations in cygwin 1.7.14-2; at least for my installation: - Windows 7 Professional 64-bit - CYGWIN_NT-6.1-WOW64 Win7i701 1.7.14(0.260/5/3) 2012-04-25 09:41 i686 Cygwin I noticed that upon completion of a fresh install using setup.exe v2.774, though it completes without error, a *mkshortcut.exe.stackdump* file was created in the root of the installation directory ("E:\cygwin" in my case). Note that I had selected setup's feature to create both Desktop and Start Menu icons. So, I decided to investigate as best I could. After repeated testing of fresh installs (removing everything each time), and even using fresh downloaded packages each time, I found that I could consistently reproduce the result. In fact, it can be reproduced by selecting a minimal package set and installing as follows. - Run setup to download from the mirror of your choice, selecting the *default* packages (top-level) and then *toggling* the X11 category to *install*. Allow setup to resolve dependencies during the operation. - Install all that was downloaded (again, allow setup to resolve dependencies). - Allow setup to create the icons. - Observe the existence of the *mkshortcut.exe.stackdump* file in the cygwin root dir. - In addition, one of the Windows start menu Cygwin-X shortcuts is also awry. The start menu shortcut intended to be Cygwin-X/Toys/xlogo was created as xlogo.lnk# (note the .lnk#). All other X shortcuts seem to be correct (based on other previous installations). - Also, the '/etc/postinstall/X-start-menu-icons.sh.done' exists, indicating a successful operation. While the /var/log/setup.log.full file identifies both the postinstall "X-start-menu-icons.sh" and "xlaunch.sh" scripts as problematic, I only looked into the X-start-menu-icons.sh operations though I cannot identify the root cause (presumably both are suffering from the same root cause). By modifying the '/usr/X11R6/bin/X-start-menu-icons.sh' script to prefix an 'strace -o /${app}.strace ' to the mkshortcut command of the xapp function, I found that stack dumps occurred for both the *xeyes* and *xmag* shortcut creations. Yet, these two shortcuts were in fact created and are functional. However, I could not see anything that attributed to why/how the xlogo creation was getting the '.lnk#' suffix added. By the way, I deleted the Cygwin-X start menu each time to ensure the shortcuts would be recreated during each test cycle. In further troubleshooting, I found that removing the *xeyes* and *xmag* lines from the '/etc/X11/X-start-menu-icons-list' eliminates the stack dumps and no others occur (for the related script), but it does nothing to resolve the *xlogo* issue. However, removing the *xlogo* line from the list file obviously prevents its creation and the '.lnk#. does not propagate to any other shortcut either. Uncertain as to why only these specific items are affected (and is repeatable); the list file content appears normal. Please refer to the attached *files.bz2* as it includes all the setup logs, cygcheck, strace files, and an 'X-start-menu-icons.log' (created via 'bash -x /usr/X11R6/bin/X-start-menu-icons.sh 2>&1 | tee /X-start-menu-icons.log' from an elevated-priv mintty bash session). Additional info: - A *rebaseall* does not influence any change. - Also, no change when using the latest 20120504 snapshot (CYGWIN_NT-6.1-WOW64 Win7i701 1.7.15s(0.260/5/3) 20120504 03:02:19 i686 Cygwin), even after another rebaseall. - I also tried sources from two different mirrors - no difference. Hopefully this will aid the developers in diagnosing the root cause. Kind regards, Ken [-- Attachment #2: files.bz2 --] [-- Type: application/x-bzip2, Size: 320331 bytes --] [-- Attachment #3: Type: text/plain, Size: 223 bytes --] -- 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/
reply other threads:[~2012-05-05 19:47 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4FA583D9.2010100@comcast.net \ --to=kstmp001@comcast.net \ --cc=cygwin-xfree@cygwin.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).