Activity log for bug #1256034

Date Who What changed Old value New value Message
2013-11-28 16:12:51 Wilfredo Velázquez-Rodríguez bug added bug
2013-11-28 16:14:22 Wilfredo Velázquez-Rodríguez description Use case: I create standalone sbcl applications on Windows by utilizing the save-lisp-and-die feature. Most of the time, these applications are UI applications that do not use the console and instead open up their own graphical windows for the user to interact with. In these, the console window that Windows (the O.S.) provides for SBCL is distracting. The opening of IO towards this console window is done by the Windows (the O.S.) loader upon seeing the 'Portable Executable' flag "Subsystem" in the 'Optional Header' set to 3 (Windows Console). As part of my build process, I utilize a modified sbcl.exe that has its "Subsystem" flag set to 2 (Windows GUI). I feed it arguments via command-line for it to load up files etc and ultimately SB-EXT:SAVE-LISP-AND-DIE with a :TOPLEVEL specified. This has worked great, until I installed the latest Windows x86 release (1.1.12). In this release the created application crashes when launched. After some experimenting with the available SBCL releases, I found that this broke as of release 1.1.2, with 1.1.1 working fine. Notes: I've found that the application works fine when launched from a console window, crashing only on the typical case of user double-click. Releases 1.1.2 and 1.1.1 are from: http://sourceforge.net/projects/sbcl/files/sbcl/1.1.2/ and http://sourceforge.net/projects/sbcl/files/sbcl/1.1.1/ Respectively. Test case: This is a little bit of an annoying thing to test because the use is a little esoteric, but here's my attempts at providing the least painful test case I can think of: 1) Copy sbcl.exe, making it sbclw.exe 2) Edit sbclw.exe to modify the Optional Header's Subsystem field to 2 (from 2). * There are various ways of doing this.. - I typically use the PE Editor from http://sourceforge.net/projects/pe-tools/ for doing this manually. - Alternatively, I can provide a lisp function that performs the modification programmatically 3) Create a shortcut to sbclw.exe, probably set its start directory to something predictable (C:\home\) and set its command-line arguments to --eval "(progn (with-open-file (ignore \"sbcltest.out\" :direction :output :if-exists :supersede)) (exit :code 0))" 4) Run sbclw through the shortcut through explorer. Notice that the file "sbcltest.out" is not created. 5) Run sbclw.exe at the command line with the same arguments: sbclw.exe --eval "(progn (with-open-file (ignore \"sbcltest.out\" :direction :output :if-exists :supersede)) (exit :code 0))" Notice the file "sbcltest.out" is not created. Windows occasionally catches the crash and reports: Problem signature: Problem Event Name: BEX Application Name: sbclw.exe Application Version: 0.0.0.0 Application Timestamp: 524e56e8 Fault Module Name: StackHash_e07c Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Offset: 00000000 Exception Code: c0000005 Exception Data: 00000008 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: e07c Additional Information 2: e07c7abd1e6e01ceb89acff9ddb767b4 Additional Information 3: e9af Additional Information 4: e9af0ada594c3a11c2328b3bdf30b090 I'm going to get myself learned up on SBCL source and see if something stands out to me in-between these changes that might cause this to break. Use case: I create standalone sbcl applications on Windows by utilizing the save-lisp-and-die feature. Most of the time, these applications are UI applications that do not use the console and instead open up their own graphical windows for the user to interact with. In these, the console window that Windows (the O.S.) provides for SBCL is distracting. The opening of IO towards this console window is done by the Windows (the O.S.) loader upon seeing the 'Portable Executable' flag "Subsystem" in the 'Optional Header' set to 3 (Windows Console). As part of my build process, I utilize a modified sbcl.exe that has its "Subsystem" flag set to 2 (Windows GUI). I feed it arguments via command-line for it to load up files etc and ultimately SB-EXT:SAVE-LISP-AND-DIE with a :TOPLEVEL specified. This has worked great, until I installed the latest Windows x86 release (1.1.12). In this release the created application crashes when launched. After some experimenting with the available SBCL releases, I found that this broke as of release 1.1.2, with 1.1.1 working fine. Notes: I've found that the application works fine when launched from a console window, crashing only on the typical case of user double-click. Releases 1.1.2 and 1.1.1 are from: http://sourceforge.net/projects/sbcl/files/sbcl/1.1.2/ and http://sourceforge.net/projects/sbcl/files/sbcl/1.1.1/ Respectively. Test case: This is a little bit of an annoying thing to test because the use is a little esoteric, but here's my attempts at providing the least painful test case I can think of: 1) Copy sbcl.exe, making it sbclw.exe 2) Edit sbclw.exe to modify the Optional Header's Subsystem field to 2 (from 2).   * There are various ways of doing this..     - I typically use the PE Editor from http://sourceforge.net/projects/pe-tools/ for doing this manually.     - Alternatively, I can provide a lisp function that performs the modification programmatically 3) Create a shortcut to sbclw.exe, probably set its start directory to something predictable (C:\home\) and set its command-line arguments to   --eval "(progn (with-open-file (ignore \"sbcltest.out\" :direction :output :if-exists :supersede)) (exit :code 0))" 4) Run sbclw through the shortcut through explorer. Notice that the file "sbcltest.out" is not created. 5) Run sbclw.exe at the command line with the same arguments:   sbclw.exe --eval "(progn (with-open-file (ignore \"sbcltest.out\" :direction :output :if-exists :supersede)) (exit :code 0))"   Notice the file "sbcltest.out" is now created. Windows occasionally catches the crash and reports: Problem signature:   Problem Event Name: BEX   Application Name: sbclw.exe   Application Version: 0.0.0.0   Application Timestamp: 524e56e8   Fault Module Name: StackHash_e07c   Fault Module Version: 0.0.0.0   Fault Module Timestamp: 00000000   Exception Offset: 00000000   Exception Code: c0000005   Exception Data: 00000008   OS Version: 6.1.7601.2.1.0.256.48   Locale ID: 1033   Additional Information 1: e07c   Additional Information 2: e07c7abd1e6e01ceb89acff9ddb767b4   Additional Information 3: e9af   Additional Information 4: e9af0ada594c3a11c2328b3bdf30b090 I'm going to get myself learned up on SBCL source and see if something stands out to me in-between these changes that might cause this to break.
2013-11-28 17:17:27 Paul Khuong sbcl: status New Confirmed
2013-11-28 17:17:31 Paul Khuong sbcl: importance Undecided Medium
2013-12-01 01:39:46 Wilfredo Velázquez-Rodríguez attachment added 1256034.patch https://bugs.launchpad.net/sbcl/+bug/1256034/+attachment/3920518/+files/1256034.patch
2013-12-01 09:28:03 Stas Boukarev sbcl: status Confirmed Fix Committed
2014-01-29 12:21:15 Christophe Rhodes sbcl: status Fix Committed Fix Released
2014-02-22 18:28:01 Wilfredo Velázquez-Rodríguez attachment added handle-woes.patch https://bugs.launchpad.net/sbcl/+bug/1256034/+attachment/3991699/+files/handle-woes.patch