• Mark (55/55) Jul 26 2018 Hello,
• Stefan Koch (2/58) Jul 26 2018 Have you tried using -profile-gc ?
• Mark (3/7) Jul 27 2018 No, I haven't. Ill give that a try and see what I find. Thanks!
• Mark (6/14) Jul 27 2018 Hmm, unfortunately that only seems to work if the program ends.
• Kagamin (1/1) Jul 27 2018 See what the program does when it consumes memory.

Mark <tigchelaarm mymacewan.ca> writes:

Hello,

I am building a toy compiler in D, and during this I ran into a 
situation.
It involves checking the header of each function, going through 
the arguments, and seeing if there is any duplicate identifiers.

I have a python script that feeds a whole bunch of source files 
that have one error of a specific type each (with an expected 
error).

The only file that causes this problem is called fnDupArgs.nerf 
(I called my language nerf).

In my mind, this is a simple check, but for some reason that I 
can't identify, it causes the entire computers memory to be 
filled up, causing swapping on the hard drive!

Here is my project: 
https://github.com/MarkTigchelaar/Nerf-Compiler-2.0

In system_test.py, that test is commented out (un comment it, 
line 135)

the source of the problem is in the file analyze_semantics.d, on 
line 36:

void add_func_args_to_local_variable_table(Function* func, ref 
SymbolTable table) {
     string[] func_args = func.arg_names.dup;
     string[] arg_types = table.get_function_args(func.name);
     if(func_args.length != arg_types.length) {
         throw new Exception("Number of function variables is not 
the
                             same as number of types for same 
function."); <--compiler error
     }
     for(int i = 0; i < func_args.length; i++) {
         table.add_local_variable(func_args[i], arg_types[i]); <-- 
line 36
     }
}

this calls the symbol tables method in the file symbol_table.d, 
on line 129:

     final void add_local_variable(string variable, string type) { 
<-- line 129
         import fn_header_syntax_errors: duplicate_fn_args;
         if(!is_declared_variable(variable)) {
             variable_table[variable] = type;
             variables_at_scope_level[scope_level] ~= variable;
         } else {
             duplicate_fn_args();
         }
     }

Now I've been staring at this for an hour and a half. If you 
leave the one test commented out, everything passes, and all is 
well.

But if you run that one extra test, it tries to swallow up all 
the available memory on the computer.

I genuinely have 0 clue why this is happening, could someone help?
If I can't figure this one out, my compiler will have a hole in 
it's semantic checking that I don't want.


Thanks!

Stefan Koch <uplink.coder googlemail.com> writes:

On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote:
 Hello,

 I am building a toy compiler in D, and during this I ran into a 
 situation.
 It involves checking the header of each function, going through 
 the arguments, and seeing if there is any duplicate identifiers.

 I have a python script that feeds a whole bunch of source files 
 that have one error of a specific type each (with an expected 
 error).

 The only file that causes this problem is called fnDupArgs.nerf 
 (I called my language nerf).

 In my mind, this is a simple check, but for some reason that I 
 can't identify, it causes the entire computers memory to be 
 filled up, causing swapping on the hard drive!

 Here is my project: 
 https://github.com/MarkTigchelaar/Nerf-Compiler-2.0

 In system_test.py, that test is commented out (un comment it, 
 line 135)

 the source of the problem is in the file analyze_semantics.d, 
 on line 36:

 void add_func_args_to_local_variable_table(Function* func, ref 
 SymbolTable table) {
     string[] func_args = func.arg_names.dup;
     string[] arg_types = table.get_function_args(func.name);
     if(func_args.length != arg_types.length) {
         throw new Exception("Number of function variables is 
 not the
                             same as number of types for same 
 function."); <--compiler error
     }
     for(int i = 0; i < func_args.length; i++) {
         table.add_local_variable(func_args[i], arg_types[i]); 
 <-- line 36
     }
 }

 this calls the symbol tables method in the file symbol_table.d, 
 on line 129:

     final void add_local_variable(string variable, string type) 
 { <-- line 129
         import fn_header_syntax_errors: duplicate_fn_args;
         if(!is_declared_variable(variable)) {
             variable_table[variable] = type;
             variables_at_scope_level[scope_level] ~= variable;
         } else {
             duplicate_fn_args();
         }
     }

 Now I've been staring at this for an hour and a half. If you 
 leave the one test commented out, everything passes, and all is 
 well.

 But if you run that one extra test, it tries to swallow up all 
 the available memory on the computer.

 I genuinely have 0 clue why this is happening, could someone 
 help?
 If I can't figure this one out, my compiler will have a hole in 
 it's semantic checking that I don't want.


 Thanks!

Have you tried using -profile-gc ?

Mark <tigchelaarm mymacewan.ca> writes:

On Friday, 27 July 2018 at 06:20:57 UTC, Stefan Koch wrote:
 On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote:
 Hello,


...
 Have you tried using -profile-gc ?

No, I haven't. Ill give that a try and see what I find. Thanks!

Mark <tigchelaarm mymacewan.ca> writes:

On Friday, 27 July 2018 at 11:50:11 UTC, Mark wrote:
 On Friday, 27 July 2018 at 06:20:57 UTC, Stefan Koch wrote:
 On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote:
 Hello,


 ...
 Have you tried using -profile-gc ?

 No, I haven't. Ill give that a try and see what I find. Thanks!

Hmm, unfortunately that only seems to work if the program ends. 
However, using handy writelns Im tracing the problem down to a 
section before all that code.

Maybe I should have just slept on the problem.

Thanks anyways!

Kagamin <spam here.lot> writes:

See what the program does when it consumes memory.