File closed unexpected during read loop when #PB_Any is used

[DarkDragon]

What other commands or APIs are you using? Maybe try hooking the windows CloseHandle command in your own application somehow to check when it gets closed. With the C backend you might be able to attach with lldb or gdb (maybe even without C backend, but then you don't have debug symbols).

[infratec]

API is only used for detecting network changes.
And this is only in a listening way.

The program is crossplatform and I avoided API when ever it is possible.

All of this can not explain why it is working without problems when I use fixed numbers.

With #PB_Any it happens latest after 20 program starts.
With fixed number I was not able to reproduce it.

[skywalk]

I am curious if you set the constant to the same value returned by PB_ANY?
Does this happen regardless of file sizes?
If it happens after 20 tries of the program, did the original programs actually close out completely?

Rename your app(app1.exe, app2.exe) each time you start.

Is this a memory leak?

[Demivec]

Can you provide a program skeleton for the program that causes the issue. I know you provided a written outline of some of the details but this is hard to test.

The important parts of the skeleton would be all file operations for open and closing and reading (since you said there are no write operations), thread creation and operations for the same. Not needed would be any data read from a file unless it causes a file action such as closing or opening a file. Anything GUI related would also not be needed.

I haven't experienced the issue but would like to see if I can produce it and then find solutions.

[idle]

I assume your using readfile with #PB_File_SharedRead and that your file handle is an integer rather than a long
in case it's getting clobbered on the stack. You could also try it without buffering.

[BarryG]

@infratec: You never said which version of PureBasic you're using. We know that 6.10 brought some crashing issues due to long-vs-integer data types, so I'd at least try a pre-6.10 version and see if the problem still occurs with that.

[AZJIO]

@infratec: You never said which version of PureBasic you're using.

https://www.purebasic.fr/english/viewto ... 28#p623028

[BarryG]

Dang, I only paid attention to his first post.

[DarkDragon]

API is only used for detecting network changes.
And this is only in a listening way.

The program is crossplatform and I avoided API when ever it is possible.

Yes, but when it's being closed the API will likely be called. And then you could check where the call happened. You can also do it on Linux with fclose/close or so.

Ollydbg might be helpful as well.

[infratec]

The program is always completely closed before I start it again.

As you can see in the screenshot I'm running it from the IDE with Purifier and a granularity of 1, 1, 1, 1.

For all file operations I used #PB_Any, so it is impossible that the same value is used.
As I can say, at this point no other file operations are active.
File operations are only for reading/writing the INI file and for this CSV file.
Since it is at the program start, the ini file was already read, and the user (I) was not able to change something which
requires a write of the INI file.

There is no action of defender active, and I don't use an other virus scanner.

As I told you, I was not able to write a multithreaded small program which can reproduce this behaviour.
I can not give away the sourcecode. It is a phone program for a customer with SIP and a WEB GUI communicating via WebSocket.
At this early moment I fetch the contacts from the PBX via HTTPRequests and write them in the file. Then I reopen it and read it line by line.
And sometimes it happens, but only with #PB_Any. I use the standard ReadFile() without optional parameters.

It is really difficult.

On monday I will try to find out from where the file close is comming.

[PBJim]

I had a particular interest in this, as I also maintain a thread-dependent application that manages random access data files inside those threads. I recently asked on the forum about the maximum concurrent open files. In the end, I carried out the testing myself and I found that I could open 30,000 files with #PB_Any and keep them open, furthermore that I could write to them all and close them. In my testing, I didn't lose any of the files.

The only thing I can foresee with your case, is that it's caused by a timing problem that hasn't been considered, for instance a thread still running when you don't realise it. I think you say that you close the file in the threads only, but it wasn't clear to me from your code screenshot, if that section is the thread.
I don't really follow this though :

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.

You're creating the file in the thread, but I don't follow whether you're passing the file no. back from the same thread in which you create it. You say you return the file as a ProcedureReturn, but threads can't pass back a ProcedureReturn.

I have just converted my recent test code to use threads, to see if any #PB_Any-opened file gets closed, but it works fine. It probably isn't close to what you're doing, but just thought I'd try to reproduce. Sometimes in the commercial world, we can't afford to spend time and cost trying to resolve a weird problem like this, so we have to use the workaround.

[BarryG]

infratec said it works if #PB_Any isn't used, so the crux of the issue is using constants vs using #PB_Any.

[infratec]

The whole thing is inside one thread.

It calls Mein_gntel_GetContactCDV() this returns the file handle.
And then it is read line by line and afterwards it should be closed by the code.