Hi Allen/Forum
I've been fed up with how bloated visual studio has become and decided to try out 4coder. I thought I would try it out at work, we have quite a large project, around 8100 .cpp .h .inl and .hpp files.
I tried an open all code recursive command and this crashed 4coder. It looked like it was trying to dereference a nullptr or something, perhaps it was running out of memory because this is a tonne of code to have loaded at once.
I guess my first question is that is this a legitimate bug? or maybe its just unreasonable to perform an open all code on a project of this size. If it literally loads the contents of said files into buffers then it probably isn't a reasonable assumption. What is the upper limit of files that can be loaded at once?
Secondly, would Allen consider releasing symbols for 4coder in future so we can debug/fix issues like this ourselves?
I've been fed up with how bloated visual studio has become and decided to try out 4coder. I thought I would try it out at work, we have quite a large project, around 8100 .cpp .h .inl and .hpp files.
I tried an open all code recursive command and this crashed 4coder. It looked like it was trying to dereference a nullptr or something, perhaps it was running out of memory because this is a tonne of code to have loaded at once.
I guess my first question is that is this a legitimate bug? or maybe its just unreasonable to perform an open all code on a project of this size. If it literally loads the contents of said files into buffers then it probably isn't a reasonable assumption. What is the upper limit of files that can be loaded at once?
Secondly, would Allen consider releasing symbols for 4coder in future so we can debug/fix issues like this ourselves?
Hi
Sorry about the crash! It does sound like it might be an out of memory situation. The data structures should be able to handle millions of files, if those files are all empty, but it might be running into problems trying to load the data for all of the files. The fact that it crashes instead of asserting does count as a bug in my book though.
I have tried to release debug symbols before, but I never really liked how it worked out with bloated file sizes. My packaging system is a lot stronger now so maybe I'll set up a new way to ship debug builds alongside release builds.
Thanks for the bug report and suggestion!
Sorry about the crash! It does sound like it might be an out of memory situation. The data structures should be able to handle millions of files, if those files are all empty, but it might be running into problems trying to load the data for all of the files. The fact that it crashes instead of asserting does count as a bug in my book though.
I have tried to release debug symbols before, but I never really liked how it worked out with bloated file sizes. My packaging system is a lot stronger now so maybe I'll set up a new way to ship debug builds alongside release builds.
Thanks for the bug report and suggestion!
Hi,
I have the same issue, which seems to be version and platform independent.
The amount of files I can open is limited to 775. If there is one more file, 4coder will crash.
Here a batch file for reproducing it.
I have the same issue, which seems to be version and platform independent.
The amount of files I can open is limited to 775. If there is one more file, 4coder will crash.
Here a batch file for reproducing it.
1 2 3 4 | @echo off
FOR /L %%G IN (1,1,776) DO (
echo %%G > file%%G.cpp
)
|
Hmm thanks for letting me know. I'll try to setup a test to recreate it. As I said in the previous post in this thread, it's likely not just a matter of the number of files, but the size of all the files too, so my recreation might not be exact, but I'll see what I can do.
Edited by Allen Webster
on
UPDATE:
Just fixed some bugs with listers that would cause crashes when there were too many items in the list. This isn't an exact match for the description of this bug as no one has said you have to have a lister open for this bug to occur. I just did open_all_code_recursive on the files generated from the batch script (the 776 files thing) and had no crashes during the open all code command or while looking at lists of the buffers. I am not convinced I've actually solved the problem but I cannot reproduce it with my current build. If it's still a problem in the next build let me know and we can dig in even more.
Just fixed some bugs with listers that would cause crashes when there were too many items in the list. This isn't an exact match for the description of this bug as no one has said you have to have a lister open for this bug to occur. I just did open_all_code_recursive on the files generated from the batch script (the 776 files thing) and had no crashes during the open all code command or while looking at lists of the buffers. I am not convinced I've actually solved the problem but I cannot reproduce it with my current build. If it's still a problem in the next build let me know and we can dig in even more.