View Ticket
Not logged in
Ticket UUID: 4884dee3a1aaf006654ac94d25f92709961241fd
Title: Fossil server crashes on Windows with custom CMD.exe command-line AutoRun
Status: Open Type: Code_Defect
Severity: Minor Priority:
Subsystem: Resolution: Open
Last Modified: 2010-03-06 02:27:21
Version Found In: [9c5322463b] 2010-01-12 14:10:13 UTC
Description & Comments:
Operating System: Windows XP
Fossil Version: >fossil ver
This is fossil version [9c5322463b] 2010-01-12 14:10:13 UTC

I recently changed my "\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\AutoRun" REG_SZ registry entry from "" to "cd \" so my command-line prompts (cmd.exe) would start up at the root (as opposed to C:\Documents and Settings\__USER_GOES_HERE__), and this seemed to effect fossil's server detrimentally. Whenever I would try to connect to the server, the fossil processes spawned by the server processes would crash, citing "ntdll.dll" in the Windows crash error report.

After looking around, I'm finding empty files with names like "fossil_server_P8080__out1.txt" in my root. (C:\)

I'm able to reproduce and fix this anomaly by changing the aforementioned registry entry from "cd \" to "" and back.

This is likely a problem with Windows more so than Fossil.


drh added on 2010-01-21 03:05:29:
The "fossil ui" and "fossil server"] commands make use of the system() api to run subordinate instances of fossil (one instance for each incoming HTTP request.) Those subordinate fossil commands expect to run in the same directory as the main fossil instance. I suppose messing the registry as you have breaks that assumption.


eric added on 2010-01-21 19:19:59:
The autorun trick is suggested all over the internet, but most of them don't mention the problems. http://techbrahmana.blogspot.com/2009/10/changing-start-up-directory-of-command.html does mention problems with build systems, and explains two other ways to get what was wanted.

The problems will happen with many programs which start other programs, it is very definitely not Fossil-specific.


anonymous claiming to be RBerteig added on 2010-03-06 02:27:21:
That registry hack seems like a Bad Idea(TM) to me.

Much safer is to locate each shortcut you use to launch the command prompt, and adjust its Start In property to suit your needs. It is also possible to set the command line in the shortcut (edit the Target property) to something like CMD /K PRESETS.BAT to process PRESETS.BAT (provide a fully-qualified name for that, of course, and be careful to quote paths with spaces) before landing at an interactive prompt. Again, set the Start In as needed, or put a CD command in the PRESETS.BAT.

I often use this technique to describe command prompts with environment variables as needed for various cross-development tool chains which otherwise would require conflicting definitions for environment variables like INCLUDE and friends. The Microsoft Visual Studio installer sets up something similar, as well as the Windows Device Driver Kit.