#41 [fork] causes interact problem on hpux 11iv1

open
nobody
None
5
2007-07-19
2007-07-19
George Morrison
No

I may have stumbled across a bug with expect 5.43.0 & tcl 8.4.15. I was creating a script based on dislocate using expect 5.37.2 and tcl 8.3.4. I ran into some problems and decided to upgrade to the latest expect before I went further. Long story short(er), I discovered the unmodified dislocate script does not work in expect 5.43.0 (the “Escape character is..” line appears but nothing else). On the same system, the same dislocate script works fine with 5.37.2. I created a script to try to track down the problem and came up with a very short script (25 lines) that does exactly that. It basically is just the “child” part of the code; I created two FIFOs manually (1.o and 1.i) and use cat commands to keep them open while I run the bug.exp script (attached). What I found is that if [fork] is used to put the script in the background, 5.43.0 hangs running interact whereas 5.37.2 works as expected. My OS is HP-UX 11.11 (aka 11iv1). In summary:

+-------------------+--------------------+
|5.37.2 | 5.43.0 |
+-------+-----------+--------+-----------+
|[fork] | No [fork] | [fork] | No [fork] |
+-------+-----------+--------+-----------+
| Works | Works | Hangs | Works |
+-------+-----------+--------------------+

Test commands with [fork]:
expect bug.exp
cat < /dev/zero > 1.o &
cat 1.i

Test commands with no [fork]:
expect bug.exp &
cat < /dev/zero > 1.o &
cat 1.i

Any help or guidance you can provide would be greatly appreciated.

George Morrison

Discussion

  • Script demonstrating potential interact/fork bug

     
    Attachments
  • Logged In: YES
    user_id=1849069
    Originator: YES

    I have discovered the following information since posting the bug:

    1. The "bug" also occurs on HP-UX 11iv2 (same TCL and expect versions).
    2. If I recompile the former expect and TCL versions (5.37.2 & 8.3.4, respectively), the "bug" appears.
    3. The expect and TCL tests pass.
    4. A system call trace shows the expect that fails is using kernel threads whereas the expect version that does not fail has no kernel thread calls.

    So the "bug" appears to be thread related; any clue where to start looking?

     
  • Logged In: YES
    user_id=1849069
    Originator: YES

    I have discovered the following information since posting the bug:

    1. The "bug" also occurs on HP-UX 11iv2 (same TCL and expect versions).
    2. If I recompile the former expect and TCL versions (5.37.2 & 8.3.4, respectively), the "bug" appears.
    3. The expect and TCL tests pass.
    4. A system call trace shows the expect that fails is using kernel threads whereas the expect version that does not fail has no kernel thread calls.

    So the "bug" appears to be thread related; any clue where to start looking?