os_create_thread() crash in 1.3.1.636b

[Dorf]

This is the line from the error file:
2/24/2013 4:43 PM: Everything 1.3.1.636b: .\src\os.c(4915): os_create_thread(): failed to create thread 8: 0041f0c0

I'm using win8x64 w classic start menu.
At the time i had an everything window open with a search and i was trying to change the search term to start another.

[void]

Thanks for the bug report.

This error occurs when the system is out of memory.

Do you have the Everything Service installed?

It is possible this is a memory leak in Everything.
Is Everything's memory usage increasing over time?

[Dorf]

I don't think the service is installed. I don't see it running. Should i reinstall it with the service?

This system has some huge drives with a LOT of files.

[void]

I don't think the service is installed. I don't see it running. Should i reinstall it with the service?

If its not installed, then no do not install it.
There is a minor leak in 1.3.1.636b with the service client.
However, this should not cause out of memory issues.

Please monitor Everything's memory usage and handle count in task manager.
please let me know if Everything's memory usage grows to +100mb or the handle count increases to +100 handles from when you first run Everything.

[Dorf]

I do see an everything service, it is stopped though.
In process explorer i see: private bytes 110924, working set 116772k, 316 handles. Everything has been running half a day. i dont know what it was at start, but i'll check over time now.

[Dorf]

It's upto 144388k, 150340k, 316. From just running in background in the taskbar

[void]

It is normal for Everything's memory usage to almost double over time.
However, there is most likely an issue/leak if Everything's memory usage continues to grow pass the initial memory usage x2.

Please keep an eye of the memory usage...

[Dorf]

It just crashed again. There were 2 new entries in the errorlog, but only saw one error poppup:
2/26/2013 7:39 AM: Everything 1.3.1.636b: .\src\os.c(4915): os_create_thread(): failed to create thread 8: 0041cfe0
2/26/2013 7:39 AM: Everything 1.3.1.636b: .\src\os.c(4915): os_create_thread(): failed to create thread 8: 004511a0

After the crash popup the memories were about 344000k, 155000k.

Once i restart it (it has to rebuild the indexes) it is at 83000, 92000, 200handles

[void]

I have found if you have Enable only in Explorer unchecked in Class Shell File operations Everything will leak system resources when creating/destroying a thread.

Do you have this option unchecked?

[Dorf]

I have found if you have Enable only in Explorer unchecked in Class Shell File operations Everything will leak system resources when creating/destroying a thread.

Do you have this option unchecked?

I dont see an option like that anywhere. Where is it located? With classic shell, i only installed the Start menu part, not the classic explorer if that is what you mean.

[void]

It is a part of Classic explorer under File operations with all settings checked.

[Dorf]

Oh i never installed classic explorer, just the start menu part. I can do it in a bit when i update the version and see how it goes with that setting.

[void]

Classic shell should not be an issue if you have not installed Classic Explorer, I will keep looking into this problem...

[Dorf]

After almost 2 weeks of no crash, it happened again. This time i think after awaking from sleep/hibernate. The memory usage had slowly been increasing to those larger figures i posted.

I should note i dont restart this computer that much. Usually only when MS patches require it. The rest of the time it sleep/hibernates when not in use.

[void]

I have been running tests with sleep / hibernate and have not run into any issues...

I will continue to look into this problem...
I will add some more debugging tools to the next release to help in finding the problem.

[Dorf]

This is still happening in 643b

[void]

Thanks for the update... I am looking into this now.

[void]

Could you please send some debug output with the latest beta release?

This beta version will show extra debug information and memory usage when creating threads.

[void]

Does this issue occur in 647b?

[Dorf]

I'm using the newest beta. I haven't seen the bug in a long time, but i disabled powersaving mode a while ago so that could be why. I'll reenable it to try and replicate it.

BTW, I noticed if you open the debug window with ctrl~, then close the debug window, that closes everything and seems to delete indexes. Restarting everything when its closed in that manner does a index rebuild.

[void]

Thanks for the update.

BTW, I noticed if you open the debug window with ctrl~, then close the debug window, that closes everything and seems to delete indexes. Restarting everything when its closed in that manner does a index rebuild.

Closing the debug console window will terminate the Everything process.
You can use Ctrl + ~ to toggle the console window without closing Everything.

Because the process is terminated, Everything does not have a chance to save the database to disk and must rebuild it when you restart Everything.

[Dorf]

Still havent seen this error again. The debug window has been open the whole time and machine rebooted about twice a week, went in/out of sleep mode tons of times.

[void]

Thanks for the update.

Hopefully this problem has been fixed with the current implementation of ''reusing threads''.

Reusing threads does use a few extra resources (~4k memory and 3 handles per thread).

For reference, reusing threads is enabled by default.
Reusing threads can be disabled by setting the ini option:

Code: Select all

reuse_threads=0