Here's another Darcs failure.

This is on Windows with darcs 1.0.9, using ssh.  The local repo is not partial.  I was pulling from the main GHC repo.

As usual I'm stumped.  A subsequent 'darcs pull' said "no remote changes to pull in".  So maybe it's ok.  But the failure message is alarming

Simon

[Add some x86/Linux outputs
Ian Lynagh <igloo@earth.li>**20080603145857]
[Add x86-linux output for a couple of benchmarks running the slow way
Ian Lynagh <igloo@earth.li>**20080603164937]
diffing dir...
Applying patches to the local directories...
diffing dir...
darcs failed: 512 at ./darcs-all line 59.

Attachments

• unnamed

No idea.  The error message is from the darcs-all script (and not darcs), but I
do not know why it would be exiting 512.

I did not find any interesting instances of the string '512' in our source code.

Thoughts, anyone?

I've no ideas.

David

It's especially weird since exit code is a single byte under POSIX. Dunno about
Windows though. Might be something else than darcs is generating that? I actually
don't know zilch about Windows, but could the 512 be a symptom of a violent
termination, by something akin to a Unix signal? Out of memory, whatever? I can't
extract any useful information from that myself. I think there's basically no way
to know what's going wrong from the report...

Does this help at all?
  http://coding.derkeiler.com/Archive/Python/comp.lang.python/2004-05/3713.html

In the sense that the exit code isn't /really/ 512?

Maybe #haskell would know what it means when we get an exit 512 from a Haskell
program?

Now, then, 512 sounds like a bug in whatever has been calling darcs. So what does
an exit code 2 mean with darcs? And is the caller bug really forgetting to shift
the value from the OS, or is it mangling it differently? (I believe applying
WEXITSTATUS under POSIX.)

I think we need somebody on Windows to play with the darcs-all script that GHC
uses.  Maybe boil it down and make a simple script that calls something that
trivially exits 2 and see if it thinks it's exiting 512.

> Now, then, 512 sounds like a bug in whatever has been calling darcs.
> So what does an exit code 2 mean with darcs

So I grepped ExitFailure in the source and only found this:

withSignalsHandled job = do
    thid <- myThreadId
    mapM_ (ih thid) [sigINT, sigHUP, sigABRT, sigTERM, sigPIPE]
    catchJust just_usererrors (job' thid `catchSignal` defaults)
              die_with_string
    where defaults s | s == sigINT = ew s "Interrupted!"
                     | s == sigHUP = ew s "HUP"
                     | s == sigABRT = ew s "ABRT"
                     | s == sigTERM = ew s "TERM"
                     | s == sigPIPE = exitWith $ ExitFailure $ 1
                     | otherwise = ew s "Unhandled signal!"
          ew sig s = do hPutStrLn stderr $ ("withSignalsHandled: " ++ s)
                        resethandler sig
                        raiseSignal sig -- ensure that our caller knows how we died
                        exitWith $ ExitFailure $ 1
          die_with_string e | take 6 e == "STDOUT" =
                do is_pipe <- stdout_is_a_pipe
                   when (not is_pipe) $
                        hPutStrLn stderr $ "\ndarcs failed:  "++drop 6 e
                   exitWith $ ExitFailure $ 2
          die_with_string e = do hPutStrLn stderr $ "\ndarcs failed:  "++e
                                 exitWith $ ExitFailure $ 2
#ifdef WIN32
          job' thid =
             withCtrlCHandler (throwDynTo thid $ SignalException sigINT) job
#else
          job' _ = job
#endif

Does that give us any clues?