Bug 13988 – Colon in file path crashes WebKit Nightly

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Glenn Marshall]

Including a slash in the file name causes a very fast crash on startup.  Yes, I know that the standard Unix directory delimiter is a slash, and thus that this isn't that bizarre.  

On the other hand, the Finder allowed it, and since the Mac Just Works virtually all the the time, I forged ahead boldly....  

I submit that having slashes in nightly builds isn't that unusual a thing to do - I was naming the folder containing the WebKit I just downloaded to its date, June 2/07, expecting I would be having multiple WebKit nightlies downloaded, and waiting to keep them straight.

The workaround is trivial - I replace the slash with a dash and tried again - it worked, no problem.

Regardless, this behaviour isn't at all Mac Like, and, at a minimum, a nice message should be given.  

It would appear that Finder has established a precedent, so I would submit that Safari should handle it in the same way, i.e. Just Work.   This full solution, if involved to do, is clearly, IMHO, lower priority than fixing the crash.

[Glenn Marshall]

(In reply to comment #0)

s/waiting to keep them straight/wanting to keep them straight/

[David Kilzer (:ddkilzer)]

Thanks for the bug report, Glenn!

Could you post the stack trace (from CrashReporter)?  It will be the last entry in ~/Library/Logs/CrashReporter/Safari.crash.log, or just generate another one and copy and paste the text in the CrashReporter window to a comment in this bug.

Also, could you please post more explicit, step-by-step instructions to reproduce the bug?  I tried this, but it didn't work:

1. Create a folder named "June 2/07" in the Finder.
2. Copy an HTML file into the directory.
3. Double-click on the HTML file to open it in Safari.
4. Change the ":" to "/" in the URL, then hit Enter.
5. Safari should crash.  (It didn't for me.)

I also tried:

1. Create a folder named "May 28/07" in the Finder.
2. Copied WebKit nightly r21834 into the folder.
3. Double-click on the nightly DMG to mount it.
4. Double-click on the gold Safari icon to launch the nightly.
5. Nigthly should crash.  (It didn't crash for me.)

Please note that it's more useful for us to know the revision number ("rNNNNN") of the WebKit nightly than the date due to time zone differences and the fact that sometimes there is more than one nightly build per date.  Thanks again!

[Glenn Marshall]

David:

Fast work! :)

In more detail:

1.  I refreshed with the latest build, r21970.

2.  I downloaded it to: (\/ indicates a literal slash in the filename, / is the directory separator)

/Applications/downloaded/WebKit nightlies/June 4\/07/WebKit June 4\/07

Precisely:
  - made a new folder in WebKit nightlies via shift+flower+N in the finder
  - renamed it in the finder to (no leading spaces):
      June 4/07
  - opened it via double click
  - opened the disk image via double click
  - dragged the 2 files from the disk image to the newly created folder
  - renamed WebKit in the new folder using the finder to (no leading spaces):
      WebKit June 4/07
     
Next, I double clicked on the WebKit June 4/07 icon, near instant crash, as before.

3. I renamed it to:

/Applications/downloaded/WebKit nightlies/June 4-07/WebKit June 4-07

worked fine.

4.  I renamed it back to:

/Applications/downloaded/WebKit nightlies/June 4-07/WebKit June 4\/07

crashed again.

5.  I renamed it to:

/Applications/downloaded/WebKit nightlies/June 4\/07/WebKit June 4-07

crashed again.

6.  So, to summarize:  for me, having a literal slash in the immediate parent directory, or the root file name, or both, causes a crash.  Renaming it to remove the slash(es) makes the crash go away.  Renaming it back brings it back.

I'm surprised your second test scenario didn't produce the crash.

7.  the crashlog entries seem to be saying that the / in the filename is being interpreted as a directory.

8.  notice that I haven't upgraded to the latest version of OS X, and I don't auto upgrade.  The boot image I'm running off is rather out of date at 10.4.3, but since it works fine, and (for me) Unix people don't reboot...

8.  the last crashlog entries covering all of the retesting above (some of the tests were run twice):

**********

Host Name:      glenn-ap-marshalls-ibook
Date/Time:      2007-06-04 20:04:10.701 -0400
OS Version:     10.4.3 (Build 8F46)
Report Version: 3

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  WindowServer [54]

Version: 2.0.2 (416.12)

PID:    24058
Thread: Unknown

Link (dyld) error:

could not load inserted library: /Applications/downloaded/WebKit nightlies/June 4

**********

Host Name:      glenn-ap-marshalls-ibook
Date/Time:      2007-06-04 20:04:53.818 -0400
OS Version:     10.4.3 (Build 8F46)
Report Version: 3

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  WindowServer [54]

Version: 2.0.2 (416.12)

PID:    24061
Thread: Unknown

Link (dyld) error:

could not load inserted library: /Applications/downloaded/WebKit nightlies/June 4-07/WebKit June 4

**********

Host Name:      glenn-ap-marshalls-ibook
Date/Time:      2007-06-04 20:05:43.638 -0400
OS Version:     10.4.3 (Build 8F46)
Report Version: 3

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  WindowServer [54]

Version: 2.0.2 (416.12)

PID:    24066
Thread: Unknown

Link (dyld) error:

could not load inserted library: /Applications/downloaded/WebKit nightlies/June 4-07/WebKit June 4

**********

Host Name:      glenn-ap-marshalls-ibook
Date/Time:      2007-06-04 20:23:47.360 -0400
OS Version:     10.4.3 (Build 8F46)
Report Version: 3

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  WindowServer [54]

Version: 2.0.2 (416.12)

PID:    24080
Thread: Unknown

Link (dyld) error:

could not load inserted library: /Applications/downloaded/WebKit nightlies/June 4-07/WebKit June 4

**********

Host Name:      glenn-ap-marshalls-ibook
Date/Time:      2007-06-04 20:24:22.477 -0400
OS Version:     10.4.3 (Build 8F46)
Report Version: 3

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  WindowServer [54]

Version: 2.0.2 (416.12)

PID:    24084
Thread: Unknown

Link (dyld) error:

could not load inserted library: /Applications/downloaded/WebKit nightlies/June 4

[David Kilzer (:ddkilzer)]

Confirmed with WebKit Nightly r21834 by copying the binary to the Desktop and renaming it to "WebKit May 28/07".

If I had to guess, the path to the nigthtly binary is not being parsed correctly when it is launched.

[Glenn Marshall]

1.  I don't understand why your renaming of the folder rather than the binary (your second test scenario) didn't reproduce the problem, yet it did for me.  There might be two issues lurking here.

Care to retry by following my steps?  

2.  I suspect the program is launched correctly, and the correct path manipulation (handling the / special case) is done by the loader, but the dynamic linker isn't using the same logic, and, in particular the path manipulation logic isn't called.   

I seem to recall seeing this before on another non OS X Unix system - the linker calls a different, conceptually lower level system call that doesn't do substitutions on its paths.  I never got a good answer as to why there was a difference; it didn't seemed right to me, but I didn't pursue it.

[David Kilzer (:ddkilzer)]

(In reply to comment #5)
> 1.  I don't understand why your renaming of the folder rather than the binary
> (your second test scenario) didn't reproduce the problem, yet it did for me. 
> There might be two issues lurking here.

The difference is that I only copied the DMG file into the directory with a slash in the name.  In my second attempt to reproduce the issue when I mounted the DMG, it's path to the WebKit binary became something like /Volumes/WebKit/WebKit.app, so it didn't even know about the slash in the path where the DMG was located.  That's the difference between my steps and your steps.  (You actually copied the WebKit.app application to the folder with the slash, and/or renamed the application itself to contain a slash.)

My first set of steps was testing that an HTML file in a directory with a slash caused the issue, but that wasn't the same as your steps either.

> Care to retry by following my steps?  

I did reproduce the issue using your steps from Comment #4, although I only renamed the WebKit executable on the Desktop.  I trust the other methods produce similar crashes, and they're easy enough for others to reproduce with the detailed instructions now available.

> 2.  I suspect the program is launched correctly, and the correct path
> manipulation (handling the / special case) is done by the loader, but the
> dynamic linker isn't using the same logic, and, in particular the path
> manipulation logic isn't called.   

There is custom code used in the WebKit Nightly to launch Safari with a different DYLD path.  I believe that code may not be parsing the path correctly, although I'm not entirely sure.

[Mark Rowe (bdash)]

We just need to escape the colon in the file path before setting the DYLD_FRAMEWORK_PATH environment variable inside WebKitLauncher.

[Mark Rowe (bdash)]

Ok, so the variable that is causing the problem is DYLD_INSERT_LIBRARIES.  'dyld' terminates the program with an error if it cannot find the libraries that it points at.  The variable's value is a list of colon-separate paths.  The colon in the path to the WebKit library is tripping up 'dyld'.  The tricky part is that I can't see any way to escape the paths.  I might just have to make the launcher detect that condition and abort gracefully instead.

[Mark Rowe (bdash)]

Fix landed in r22026.

[David Kilzer (:ddkilzer)]

(In reply to comment #8)
> Ok, so the variable that is causing the problem is DYLD_INSERT_LIBRARIES. 
> 'dyld' terminates the program with an error if it cannot find the libraries
> that it points at.  The variable's value is a list of colon-separate paths. 
> The colon in the path to the WebKit library is tripping up 'dyld'.  The tricky
> part is that I can't see any way to escape the paths.  I might just have to
> make the launcher detect that condition and abort gracefully instead.

Using two (or four--the double escape) backslashes didn't work?  Did you try substituting a '?' (single-character shell glob) or '*' (multi-character shell glob)?