Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #1859 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

[mac/linux] tango.sys.Process hangs (blocker for bin/bob, after compiling first Tango module)

Reported by: Digited Assigned to: schveiguy
Priority: major Milestone: 1.0
Component: Tango Version: 0.99.9 Kai
Keywords: mac bob Cc: larsivi, mwarning

Description

Bob hangs after calling ldc or dmd to compile first tango module. Compiler compiles successfully, and bob hangs after it.

Sampling bob from mac system monitor shows this:

(ldc/import:) ./build/bin/osx32/bob -c=ldc -r=ldc -p=osx -vu .
ldc -c -I./tango/core -I./tango/core/rt/compiler/ldc -I. -I./tango/core/vendor -release -oftango-core-Array-release.o ./tango/core/Array.d 
<ldc generates .o, bob hangs here>
Sampling process 31119 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling bob (pid 31119) every 1 millisecond
Call graph:
    2525 Thread_2507
      2525 0x23be
        2525 _d_interface_vtbl
          2525 D2rt8compiler3dmd2rt6dmain24mainUiPPaZi7tryExecMFDFZvZv
            2525 D2rt8compiler3dmd2rt6dmain24mainUiPPaZi6runAllMFZv
              2525 D2rt8compiler3dmd2rt6dmain24mainUiPPaZi7tryExecMFDFZvZv
                2525 D2rt8compiler3dmd2rt6dmain24mainUiPPaZi7runMainMFZv
                  2525 0x24fb
                    2525 D3bob6MacOSX3ldcMFZi
                      2525 D3bob10FileFilter7opApplyMFDFKC5tango2io8FilePath8FilePathZiZi
                        2525 D3bob6MacOSX3ldcMFZi15__foreachbody32MFKC5tango2io8FilePath8FilePathZi
                          2525 D3bob6MacOSX7compileMFC5tango2io8FilePath8FilePathAaZAa
                            2525 D3bob10FileFilter4execMFAAaHAaAaAaZv
                              2525 D5tango3sys7Process7Process7executeMFZC5tango3sys7Process7Process
                                2525 read
                                  2525 read

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):
        read        2525
Sample analysis of process 31119 written to file /dev/stdout

Attachments

device.patch (0.6 kB) - added by mwarning on 02/15/10 15:48:36.
bugfix

Change History

02/12/10 11:54:30 changed by larsivi

Try the new binary attached to #1846

02/12/10 12:25:08 changed by mwarning

tango.sys.Process hangs in this line: "dup2(pout.sink.fileHandle(), STDOUT_FILENO);". Testcase:

import tango.sys.Process;
void main()
{
  auto p = new Process("echo \"Hello\"\n", null);
  p.execute();
}

02/12/10 13:38:14 changed by larsivi

  • owner changed from kris to schveiguy.

02/12/10 14:52:30 changed by schveiguy

  • cc set to larsivi.

Hm... I have no idea what bin or bob is. I don't understand the report at all..

Can someone with MacOS experience please explain what the issue is to a unix/windows guy? :)

02/12/10 16:20:18 changed by larsivi

You'll find various bobs under build/bin/ ;) It is a tango building app. The issue here appears to be that, on Mac OSX, Process (which bob uses) hangs.

A minimal testcase is provided by mwarning in one of the comments.

02/12/10 17:25:51 changed by Digited

larsivi, bob mac binary from #1846 for ldc worked fine, thanks! should the ticket be closed now?

02/12/10 17:54:22 changed by larsivi

No, there is still a problem with Process - although it may be a DMD bug.

02/12/10 18:20:07 changed by schveiguy

Can I duplicate this on Linux? What DMD version does this happen with? I don't have access to Mac OSX, so I don't know if I can fix this :(

Recently, dmd2 was changed to treat static array arguments as value types, I don't think dmd 1 should have been affected. But dup2 does take int[2] as an argument, so maybe this has something to do with that -- maybe it only affects MAC.

Sorry about the bob/bin ignorance, I haven't built Tango in a long time.

02/13/10 04:46:29 changed by mwarning

I have the same problem on linux. So it's probably not just a mac problem.

02/13/10 15:23:18 changed by schveiguy

  • status changed from new to assigned.
  • cc changed from larsivi to larsivi, mwarning.

dmd version?

02/13/10 16:05:27 changed by mwarning

dmd 1.056.

02/15/10 12:04:17 changed by Abscissa

  • summary changed from [mac] bin/bob hangs in tango.sys.Process after compiling first Tango module to [mac/linux] tango.sys.Process hangs (blocker for bin/bob, after compiling first Tango module).

I just came across the problem too (Linux, DMD 1.057), and it's a blocker on linux for me (works fine on windows though), and I've been trying to trace it. I don't know if this helps, but what I've found out so far:

(Using the test app above, but, for simplicity, I changed the string being passed to the Process constructor to just "echo")

If you modify the line "dup2(pout.sink.fileHandle(), STDOUT_FILENO);" (ie the line that has been hangs) to "fcntl(tmp, F_DUPFD, STDOUT_FILENO);", then the program continues all the way to the line "rc = execve(path.ptr, argv.ptr, (envp.length == 0 ? environ : envp.ptr));" at which point it hangs again.

At that point the trail seems to grow cold (at least for me) because all the params to execve seem to check out ok (at least as far as I can tell). 'path.ptr' points to "/bin/echo\0" (which is correct for me). 'argv.length' is 2. 'argv[0]' points to "echo\0". 'argv[1]' is null. 'envp.length' is 1. 'envp[0]' is null.

I'm changing the summary slightly to better reflect the real issue.

02/15/10 12:05:38 changed by Abscissa

Correction to my previous post:

"fcntl(tmp, F_DUPFD, STDOUT_FILENO);"

should be:

"fcntl(pout.sink.fileHandle(), F_DUPFD, STDOUT_FILENO);"

02/15/10 12:29:32 changed by Abscissa

Another correction: DMD 1.056

02/15/10 13:06:27 changed by Abscissa

My earlier post was referring to the child process. Regardless of whether or not you make the change I mentioned in the child process, the parent process always hangs on this line:

pexec.source.input.read((cast(byte*) &status)[0 .. status.sizeof]);

If you do make change I mentioned in the child process, the child *does* successfully run echo.

Although, for all I know, I might have screwed up my own results by using Stdout for debugging output...

02/15/10 15:48:36 changed by mwarning

  • attachment device.patch added.

bugfix

02/15/10 15:49:35 changed by mwarning

Looks like the problem was an orphaned if.

02/15/10 17:28:11 changed by larsivi

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [5376]) Comment orphaned if, my mistake, thanks mwarning and wm4 for finding it, closes #1859, closes #1861