Faculty of Information Technology
Software Engineering Group

Opened 22 months ago

Last modified 10 months ago

#148 new defect

[Windows only] Fix annoying message Processor [info]: removing invalid read-select fileDescriptor:xindx:y

Reported by: Patrik Svestka Owned by:
Priority: major Milestone:
Component: default Keywords:
Cc: Also affects CVS HEAD (eXept version): no

Description

This is really annoying message every time StX has to work with files on filesystem:

Processor [info]: removing invalid read-select fileDescriptor: 9 idx: 2
Processor [info]: removing invalid read-select fileDescriptor: 15 idx: 2    

The number of messages varies time to time and is totally unpredictable.

Change History (4)

comment:1 Changed 21 months ago by Jan Vrany

This happens a lot when one browses through the code, i.e., when looking at classes and method sources.

After a quick debugging, the invalid file descriptors belong to pipes, not regular files (experimentally proved by attached Q&D debugging code).

Highly likely these pipes are those created by HGCommand when executing an hg.exe to retrieve
commit info - see NewSystemBrowser >> #updatePackageInfoForClass.


The hypothesis is that following happens if following order (there are multiple threads involved):

  1. Initially:
    • *Browser thread* runs HGCommand >> #execute, this spawns:
    • *hg command stdout reader* thread that reads and parses the output from output pipe.
    • *hg command sdferr reader* thread that reads and parses the output from error pipe.
    Reader threads may enter a read-wait, waiting for more input (thus the file goes to central select dispathing done by ProcessorScheduler)
  2. hg.exe terminates.
  3. Smalltalk enters the central select dispatching but since endpoint of one of these pipes is gone, we get EBADF, enter ProcessorScheduler >> #removeCorruptedFds and we get the message.
  4. *Browser thread* gets scheduled, closes the pipes and all is fine.

Note, that if steps 3. and 4. executes in different order, 4. first and 3. afterwards. one gets no error message.

Now, how to prove this hypothesis? How to fix it if it's true?

comment:2 Changed 21 months ago by Patrik Svestka

Testing could be, perhaps, done in a way that step 2. would be done after step 4; when the pipes are closed.

For rectification - that is more food for thought.

comment:3 Changed 20 months ago by Patrik Svestka

I have just now performed a commit via St/X on Windows. When I have tried to update to working copy (hg up -r c40c9ef127f2), while St/X was opened, I got a abort: The process cannot access the file because it is being used by another process message. After I have exited the St/X the update when smoothly:

PS C:\prg_sdk\stx_dev\stx-jv\build\stx\libbasic> hg up -r c40c9ef127f2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Maybe there could be a connection with the locked files and the message? Could it be that St/X does not correctly close handles after commits?

comment:4 Changed 10 months ago by Patrik Svestka

What is the difference between linux and windows version? Why this error does not propagate on linux?

Last edited 10 months ago by Patrik Svestka (previous) (diff)
Note: See TracTickets for help on using tickets.