I'm now taking the policy that if 4D asks me to do their QC work for them, then I'll post the problem publicly... I'm sorta tired of them not taking quality control seriously. Case and point - I gave them a test case that showed a memory leak when generating HTML documents. They narrowed it down to a memory leak in PROCESS HTML TAGS, but then told me to create a simpler test case. I was sorta floored by the request... It's a verified memory leak and they can't be bothered to do their own test case... Remarkable.
So, I've done the test case. Here's the core method... It repeatedly sets 15 variables (5 text, 5 blobs, 5 long inteters), and then calls PROCESS HTML TAGS which composes a simple page using those variables. Some of the text and blobs are a bit large - but nothing that's too big for 4D to handle.
Here's the core method in the database...
C_TEXT($path_t) C_TIME($doc) C_LONGINT($loop_l) Compiler_Test_Vars SET BLOB SIZE(test_template_x;0) SET BLOB SIZE(test_output_x;0) $path_t:=System_GetStructureFilePath +"test:test.htm" If (Test path name($path_t)#Is a document) ALERT("Can't find "+$path_t) Else DOCUMENT TO BLOB($path_t;test_template_x) $doc:=Utility_CreateDocument (System_GetStructureFilePath +"test:output:loop-counter.txt") CLOSE DOCUMENT($doc) $loop_l:=0 Repeat For ($i;1;1000) If (Not(Macintosh command down & Macintosh control down)) //put random variables on the page of different sizes... test_text1_t:=Utility_Gibberish (10;0) test_text2_t:=Utility_Gibberish (100;0) test_text3_t:=Utility_Gibberish (50;0) test_text4_t:=Utility_Gibberish (1000;0) test_text5_t:=Utility_Gibberish (75;0) SET BLOB SIZE(test_blob1_x;0) SET BLOB SIZE(test_blob2_x;0) SET BLOB SIZE(test_blob3_x;0) SET BLOB SIZE(test_blob4_x;0) SET BLOB SIZE(test_blob5_x;0) TEXT TO BLOB(Utility_Gibberish (10;0);test_blob1_x) TEXT TO BLOB(Utility_Gibberish (100;0);test_blob2_x) TEXT TO BLOB(Utility_Gibberish (1000;0);test_blob3_x) TEXT TO BLOB(Utility_Gibberish (5000;0);test_blob4_x) TEXT TO BLOB(Utility_Gibberish (10000;0);test_blob5_x) test_longint1_l:=Random test_longint2_l:=Random test_longint3_l:=Random test_longint4_l:=Random test_longint5_l:=Random PROCESS HTML TAGS(test_template_x;test_output_x) BLOB TO DOCUMENT(System_GetStructureFilePath +"test:output:output"+String($i;"0000")+".htm";test_output_x) SET BLOB SIZE(test_output_x;0) End if End for $loop_l:=$loop_l+1 $doc:=Append document(System_GetStructureFilePath +"test:output:loop-counter.txt") If (Macintosh command down & Macintosh control down) SEND PACKET($doc;"Loop "+String($loop_l)+" aborted") Else SEND PACKET($doc;"Loop "+String($loop_l)+" complete") End if CLOSE DOCUMENT($doc) Until (Macintosh command down & Macintosh control down) ALERT("Done") End if
If you want to see the memory leak in action, download the test database with the memory leak and run the method test_SimpleCacheLoop and then watch memory usage of 4D - you'll see it go up quite quickly. It's Mac only at the moment. Press Command + Control to end the test or quit 4D. In my tests it went from 57 MB of real memory to over 250 MB of real memory in about a half hour.
My point in all of this is that they need a testing routine that has test cases that stress test every command and function in their product. This is a bug that's simple to identify and catch, but it's been in their product for a long time now and no one has caught it. If a developer catches something like this 4D needs to understand it's their job, not the developer's to get to the bottom of it once the problem is validated and not the result of a coding error on the part of the developer. In the case of a memory leak, 4D should do basic checks (like writing a test database as I did) to validate the error and see if it can be reproduced easily.