Installer made with bdist_wininst segfaulting...

[Fernando Perez]

Hi all,

I am seeking advice/help from those with more win32 experience than myself. I
am trying to build a proper win32 installer for IPython, after a user did most
of the hard work. For the most part, it's working very well, but I am running
into a nasty problem, which took me a few hours to finally understand. This
smells to me like a python bug, but I could be wrong. Much googling didn't
turn up anything relevant.

Here is a brief summary: if the installer file is run from a windows drive which
is different from the one where python resides (and hence where ipython will
end up), the installer segfaults. No traceback, nothing, just a segfault
(well, one of those Windows dialogs asking me to send a binary traceback to
Redmond, but not a proper Python traceback).

The win32 laptop where I'm testing, for example, has user stuff in the D: drive,
and Python installed in C:\Python23. I was running the installer from D:\Temp,
and getting this segfault. If I run it from C:\Temp, it works perfectly.

I have put the installer here, in case someone else is willing to test this on a
different machine:

http://amath.colorado.edu/faculty/fp....6.9.win32.exe

I have narrowed down to a single os.chdir() call in the post-install script.
The code is simply:

# Lookup path to common startmenu ...
d = get_special_folder_path('CSIDL_COMMON_PROGRAMS') + r'\IPython'

# Create IPython entry ...
if not os.path.isdir(d):
os.mkdir(d)
directory_created(d)

# XXX - The binary installer segfaults here if it was being run from a
# different drive than it is trying to change to. In my case, I have
# everything in D:, but Python lives in C:, so the chdir() call is going
# from D: to C:, and this is crashing things.

print "Current dir:",os.getcwd() # dbg
print "Going to :",d # dbg

os.chdir(d)

By forcing a return before the chdir() call, I was able to see that when the
source/destination are both on C:, it's all OK, but when the source is in D:
and the destination in C:, I get the crash.

This is really frustrating, since I'd like to be able to stop distributing .zip
sources to Windows users, and would like to be able to provide a proper
installer/deinstaller. But having this thing crash if two drives are involved
is just not acceptable.

Any help from the win32 gurus out there would be much appreciated. For
reference, the binary installer linked above was created on a Fedora3 box
running pyhton 2.3.4, with the command line:

../setup.py bdist_wininst --install-script=ipython_win_post_install.py

Cheers,

f

[Thomas Heller]

Fernando Perez <fp********@gmail.com> writes:

Hi all,

I am seeking advice/help from those with more win32 experience than myself. I
am trying to build a proper win32 installer for IPython, after a user did most
of the hard work. For the most part, it's working very well, but I am running
into a nasty problem, which took me a few hours to finally understand. This
smells to me like a python bug, but I could be wrong. Much googling didn't
turn up anything relevant.

Here is a brief summary: if the installer file is run from a windows drive which
is different from the one where python resides (and hence where ipython will
end up), the installer segfaults. No traceback, nothing, just a segfault
(well, one of those Windows dialogs asking me to send a binary traceback to
Redmond, but not a proper Python traceback).

There are a couple of known bugs in bdist_wininst, and you just reported
another one. All these bugs are related to using the
post_install_script, and show up when either (thats what I currently
remember):

- the installer is run from a readonly location,
- the installer is run from a different drive (as you reported)
- the installer installs for Python 2.4

I will fix these issues in Python 2.3.5, which will probably be out as a
release candidate this week, and in Python 2.4.1.

I urge everyone to install this release candidate, rebuild the
installer with it, and test them thoroughly.

Thanks,

Thomas

[Fernando Perez]

Hi Thomas,

Thomas Heller wrote:

Fernando Perez <fp********@gmail.com> writes:

Here is a brief summary: if the installer file is run from a windows drive
which is different from the one where python resides (and hence where
ipython will
end up), the installer segfaults. No traceback, nothing, just a segfault
(well, one of those Windows dialogs asking me to send a binary traceback to
Redmond, but not a proper Python traceback).

There are a couple of known bugs in bdist_wininst, and you just reported
another one. All these bugs are related to using the
post_install_script, and show up when either (thats what I currently
remember):

[...]

many thanks for following up on this. In my case, I realized I could avoid the
chdir() call and things were then OK. But it's good to see the bug fixed.

Best regards,

f

[Fernando Perez]

Thomas Heller wrote:

There are a couple of known bugs in bdist_wininst, and you just reported
another one. All these bugs are related to using the
post_install_script, and show up when either (thats what I currently
remember):

- the installer is run from a readonly location,
- the installer is run from a different drive (as you reported)
- the installer installs for Python 2.4

I will fix these issues in Python 2.3.5, which will probably be out as a
release candidate this week, and in Python 2.4.1.

One more small thing I just remembered...

In my testing, I noticed the installer, even when it succeeds, leaves little
temp files littering the root directory of the drive it was run from. These
seem to be the files where stdout is captured, but they should be explicitly
removed at the end.

Cheers,

f