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: link
Be 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).