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!

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 ?

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!

See what the program does when it consumes memory.

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!