Does readFile "/proc/mounts" hang for you?

David Fox

21 Jan 2009 21 Jan '09

12:20 p.m.

I posted a bug about this (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I had to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64 machine running Linux. Also, Data.ByteString.readFile "/proc/mounts" returns the empty string. Is this behavior present for others? On i386?

Attachments:

attachment.html (text/html — 490 bytes)

Show replies by date

Ertugrul Soeylemez

21 Jan 21 Jan

5:27 p.m.

David Fox wrote:

...

I posted a bug about this (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I had to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64 machine running Linux. Also, Data.ByteString.readFile "/proc/mounts" returns the empty string. Is this behavior present for others? On i386?

I can confirm this on Athlon64 X2 with GHC 6.10.1 running Linux 2.6.25. Same behavior here. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/

Krzysztof Skrzętnicki

5:43 p.m.

Same for me: Linux tenserwer 2.6.28-ARCH #1 SMP PREEMPT Tue Jan 6 10:26:22 UTC 2009 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux The Glorious Glasgow Haskell Compilation System, version 6.10.1 All best Christopher Skrzętnicki On Wed, Jan 21, 2009 at 23:27, Ertugrul Soeylemez wrote:

...

David Fox wrote:

...
I posted a bug about this (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I had to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64 machine running Linux. Also, Data.ByteString.readFile "/proc/mounts" returns the empty string. Is this behavior present for others? On i386?

I can confirm this on Athlon64 X2 with GHC 6.10.1 running Linux 2.6.25. Same behavior here.

Greets, Ertugrul.

-- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Thomas DuBuisson

9:13 p.m.

Strace tells me that its doing some crazy IO control: """ ... open("/proc/mounts", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff7470b70) = -1 ENOTTY (Inappropriate ioctl for device) select(4, [3], [], NULL, {0, 0}) = 0 (Timeout) select(4, [3], [], NULL, {134, 217727} """ I'm too rusty on any sort of low level work to draw meaning out of this without work, but... See that failed ioctl that seems to be completely ignored, right before hanging in our 'select' call? And see the select call that says 'wait 134 seconds'? If you wait it out you get: select(4, [3], [], NULL, {134, 217727} ... so its a loop that I doubt you'll exit. Tom On Wed, Jan 21, 2009 at 2:43 PM, Krzysztof Skrzętnicki wrote:

...

Same for me: Linux tenserwer 2.6.28-ARCH #1 SMP PREEMPT Tue Jan 6 10:26:22 UTC 2009 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux The Glorious Glasgow Haskell Compilation System, version 6.10.1

All best

Christopher Skrzętnicki

On Wed, Jan 21, 2009 at 23:27, Ertugrul Soeylemez wrote:

...
David Fox wrote:

...
I posted a bug about this (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I had to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64 machine running Linux. Also, Data.ByteString.readFile "/proc/mounts" returns the empty string. Is this behavior present for others? On i386?

I can confirm this on Athlon64 X2 with GHC 6.10.1 running Linux 2.6.25. Same behavior here.

Greets, Ertugrul.

-- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Gregory Collins

22 Jan 22 Jan

1:12 p.m.

Thomas DuBuisson writes:

...

open("/proc/mounts", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff7470b70) = -1 ENOTTY (Inappropriate ioctl for device)

This is to test whether the file is a terminal.

...

select(4, [3], [], NULL, {0, 0}) = 0 (Timeout) select(4, [3], [], NULL, {134, 217727}

Here's the real issue: select() doesn't work on /proc entries (or at least not that one). Here's a small C program to illustrate the behaviour: ======================================================================== #include #include #include #include int main(int argc, char** argv) { char* filename; int fd; struct timeval tv; fd_set read_fds, write_fds; int retval; if (argc < 2) return 1; filename = argv[1]; fd = open(filename, O_RDONLY | O_NOCTTY | O_NONBLOCK); FD_ZERO(&read_fds); FD_SET(fd, &read_fds); FD_ZERO(&write_fds); tv.tv_sec = 0; tv.tv_usec = 0; retval = select(fd+1, &read_fds, &write_fds, NULL, &tv); printf("select() returned %d\n", retval); printf("FD_ISSET returns %d\n", FD_ISSET(fd, &read_fds)); } ======================================================================== Running this program on "/proc/mounts" shows that select() will never report it as readable: ~/tmp/select $ gcc -o test_select test_select.c ~/tmp/select $ ./test_select /bin/ls select() returned 1 FD_ISSET returns 1 ~/tmp/select $ ./test_select /proc/mounts select() returned 0 FD_ISSET returns 0 ~/tmp/select $ G. -- Gregory Collins

Brandon S. Allbery KF8NH

23 Jan 23 Jan

3:19 a.m.

On 2009 Jan 21, at 21:13, Thomas DuBuisson wrote:

...

ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff7470b70) = -1 ENOTTY (Inappropriate ioctl for device)

This is just the test for buffering: terminal-like devices (TCGETS) are line buffered, others are block buffered.

...

select(4, [3], [], NULL, {0, 0}) = 0 (Timeout) select(4, [3], [], NULL, {134, 217727} """

I'm too rusty on any sort of low level work to draw meaning out of this without work, but...

See that failed ioctl that seems to be completely ignored, right before hanging in our 'select' call? And see the select call that says 'wait 134 seconds'? If you wait it out you get:

The ioctl() is a red herring, as stated above. I think the real problem is that files in /proc are all simulated by the kernel, and the simulation probably doesn't work very well if they're opened non- blocking and select()ed on. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

David Fox

22 Jan 22 Jan

12:16 p.m.

On Wed, Jan 21, 2009 at 9:20 AM, David Fox wrote:

...

I posted a bug about this (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I had to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64 machine running Linux. Also, Data.ByteString.readFile "/proc/mounts" returns the empty string. Is this behavior present for others? On i386?

I can now confirm that this bug also affects the i386 architecture.

Simon Marlow

9 Feb 9 Feb

8:39 a.m.

David Fox wrote:

...

On Wed, Jan 21, 2009 at 9:20 AM, David Fox mailto:ddssff@gmail.com> wrote:

I posted a bug about this (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I had to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64 machine running Linux. Also, Data.ByteString.readFile "/proc/mounts" returns the empty string. Is this behavior present for others? On i386?

I can now confirm that this bug also affects the i386 architecture.

There was a more serious underlying bug, which is now fixed. Thanks to those who reported and investigated it. Cheers, Simon

5945

Age (days ago)

5964

Last active (days ago)

List overview

Download

7 comments

7 participants

participants (7)

Brandon S. Allbery KF8NH
David Fox
Ertugrul Soeylemez
Gregory Collins
Krzysztof Skrzętnicki
Simon Marlow
Thomas DuBuisson