File closed unexpected during read loop when #PB_Any is used

[infratec]

Hi,

unfortunately I can not provide a working example.
The question is: Has anybody the same problem?

Problem:
A heavy multithreaded program.
I one thread I use CreateFile with #PB_Any, write something, close it and open it again with ReadFile and #PB_Any.
I return the File as ProcedureReturn.

In the calling Procedure I check with IsFile() if the file is valid and open,
Then I use ReadString() to read it line by line While Not Eof().
During this loop sometimes, not always, the file gets closed. I don't know who closes the file.
I can see this with SysInternals ProcessExplorer.
The program crashes. I had to add everywhere IsFile() to avoid a crash.

Now the 'fix':
If I use a fixed number at ReadFile() instead of #PB_Any, it works without problem.

The program is already running with Purifier and a granularity of 1, 1, 1, 1

I have no explanation for that.
Anyone the same experience?
Any idea about it?

[infratec]

A picture of it:


I'm not closing the file

In the started thread between the ReadFiles is no file operation.

And ... as written, if I use a fixed value instead of #PB_Any in ReadFile, it works.

[Marc56us]

Hi,

Never encountered this problem, but in this case (error without message in IDE), the first thing I would do is look at the system logs.
(Win + R > eventvwr) or (/var/log)

PS. Personally, I avoid using #PB_Any and always prefer to use Enumerations for file handles.

[infratec]

Btw. I'm using PB 6.11 x86, but this bug occured already with 5.73 (I think)

The corresponding log entries:

21 08:15:13 GetContactCSV: 200
21 08:15:13 Event_Timer: 8
21 08:15:13 Timer_GetRecentCalls start
21 08:15:13 Timer_GetRecentCalls end
21 08:15:13 ThreadRecentCalls started
21 08:15:13 ThreadRecentCalls Get 1
21 08:26:20 !!! CSV Hölle !!!

The long delay comes from standing on the break point.
The thread ThreadRecentCalls works only in memory not with files.

[infratec]

There are no events at this time in the Windows EventViewer.
Also nothing from Defender. It is a plain text file.

And ... it works with a fixed number instead of #PB_Any

[Marc56us]

Did you use Threaded for the file handle id when using #PB_Any ?

[infratec]

As written, I return the number as ProcedureReturn parameter.
It is not a global variable. It is in all cases Protected.

[sst]

I met a similar issue.
To open/read/close a file I used for number to identify the file a number #file (instead #PB_Any) obtained from Enumeration

E. g.:
Enumeration
#window
...
a lot of gadgets, menu, etc
...
#file
EndEnumeration

Error message was: #file is to large or some like that, i do not remember exactly.

To solve the issue I moved #file to begin of Enumeration and the program ran without the respective error:

Enumeration
#file
#window
...
a lot of gadgets, menu, etc
...
EndEnumeration

[sst]

I remembered.

For example:

#file=200
If CreateFile(#file,"test.txt")
CloseFile(#file)
Else
Debug ("Error")
EndIf

For #file=200 it works.
For #file=2000 it does not compile, the following error message is displayed:

"File object number is very high (over 1000), are You sure of that?"

It may or may not be the case of theOP.

Windows 7, 32 bit, PureBasic 5.71 LTS

[NicTheQuick]

I remembered.

For example:

#file=200
If CreateFile(#file,"test.txt")
CloseFile(#file)
Else
Debug ("Error")
EndIf

For #file=200 it works.
For #file=2000 it does not compile, the following error message is displayed:

"File object number is very high (over 1000), are You sure of that?"

It may or may not be the case of theOP.

Windows 7, 32 bit, PureBasic 5.71 LTS

That's normal. If you use static IDs. Purebasic creates an array internally where the ID is used as an index to the array. And at this position of the array the real handle to the file is stored. If that ID is too high you get a warning because this would mean that Purebasic needs to create a very big array where this ID can be used as an index.

Btw. Why the heck do you still use Windows 7? Are you doing some retro work?

[infratec]

@sst

a hint:

Code: Select all

Enumeration Window
  #MainWindow
  #TestWindow
EndEnumeration

Enumeration Gadget
  #Button1Gadget
  #String1Gadget
EndEnumeration

Enumeration File
  #File1
  #File2
EndEnumeration

But your problem has nothing to do with mine.

[skywalk]

Thanks for this post.
I will check my code, but I also do not remember why I use fixed constants for read/write files?
Maybe I left a comment in the code.
I use PB_Any for most all operations that allow it.

As a lark, can you run your code with a very high PB_Any constant and ignore the warming?

[mk-soft]

Have you activated Compiler Options Threadsafe?

If so, then you must perhaps protect the CreateFile and ReadFile yourself with Mutex.

[AZJIO]

Can this happen when opening a file in threads at the same time? Maybe it’s worth creating a ban on opening a file in a stream when another file is being opened?

[infratec]

Of course thread safe is enabled.

But at the same time are no other file activities. Else you would see them in the ProcessMonitor.

And ... why it does not happen when I use a fixed number instead of #PB_Any

I really invested a lot of time to find a bug. But now I gave up.
It was also not possible to create a small code to reproduce it.

Very frustrating.