dladdr failed: not available on Windows failed

[Volker Waurich]

Hi,

I get the following error dladdr failed: not available on Windows failed for almost any models I want to simulate on my Windows machine. I built omc using msys2 32bit.

The function call System.launchParallelTasks(numThreads, codegenFuncs, runCodegenFunc)); in SimCodeMain.mo causes this error. Setting num_threads to a value less than 6 works for my 6-core. But default is 12.

So something in the c-codegeneration fails:

Errors: Failed to build model: Modelica.Blocks.Examples.BooleanNetwork1Error: Failed to write to file (not open)
Error: Template error: A template call failed (a call with 0 parameters: dladdr failed: not available on Windows). One possible reason could be that a template imported function ca
ll failed (which should not happen for functions called from within template code; templates preserve pure 'match'/non-failing semantics).

As a result the following generated files are empty:
*_15syn.c, *_11mix.h, *._includes.h and hence, compilation fails due to missing references.

[Martin Sjölund]

Try setting a breakpoint in om_file_write in File.mo to debug this. The issue does not appear in Linux as far as I can tell, and this only happens if a File external object is NULL.

Also: Is there any limit on the maximum number of open files on Windows?

[Niklas Worschech]

Are there any news to this ticket. On Windows, it is no longer possible to simulate a model with the c runtime since 5 months.

[Martin Sjölund]

I did not look into this further since I got no more user input.

[Volker Waurich]

This issue might be solved by 0358b6
I have tested it quickly and the dladdr message does no longer show up.

Maybe niklwors can try it out on Windows as well?

Thanks sjoelund.se

[Adrian Pop]

This still happens on 32 bit. I tested it a bit on my computer. Whenever you set n>=6 the parallel code generation gets to File.write with a FILE pointer 0. I'll debug some more.

[Adrian Pop]

The problem is in Tpl.tokFileText which creates a File.File via the constructor using:

File.File file = File.File(getTextOpaqueFile(inText));

and then recursively calls itself via Tpl.handleTok which SOMEHOW overrides the file if there are several threads. I don't quite understand why this happens, maybe the thread stack is overrun?

[Adrian Pop]

The problem was that the given *existing* fromID input to the file constructor was actually making isNone return true. A fix is on the way.

[Adrian Pop]

Should be fixed with PR: ​https://github.com/OpenModelica/OMCompiler/pull/1493

[Adrian Pop]

Fixed in 057661/OMCompiler.

[Martin Sjölund]

Seems like an odd File interface change, passing a filename and boolean but then not using the filename. filename should be set only when opening a file (and not in the constructor). It also makes a weird default, where before you just said File() when you wanted to create a File object not bound to any file. Now you need to pass File(NONE(), "dummyFileName", true)...

And the odd behaviour of passing both an Option<File> and a boolean seems odd. The bug where isNone() returned true for existing files is not documented in the source code either, which probably would lead to the code being re-written in the future. And anyway, it just seems like a hack that avoids fixing the returned value of Option<Integer> on 32-bit Windows. It could be a quite serious issue causing multiple crashes that should have been fixed.

[Adrian Pop]

Replying to sjoelund.se:

Seems like an odd File interface change, passing a filename and boolean but then not using the filename. filename should be set only when opening a file (and not in the constructor). It also makes a weird default, where before you just said File() when you wanted to create a File object not bound to any file. Now you need to pass File(NONE(), "dummyFileName", true)...

Not true. You can do File(); without any issue as all parameters have a default.

And the odd behaviour of passing both an Option<File> and a boolean seems odd. The bug where isNone() returned true for existing files is not documented in the source code either, which probably would lead to the code being re-written in the future. And anyway, it just seems like a hack that avoids fixing the returned value of Option<Integer> on 32-bit Windows. It could be a quite serious issue causing multiple crashes that should have been fixed.

I think you're completely mistaken here. There is nothing to fix, you used Option<Integer> to pass an opaque FILE* pointer which in some cases returns true for isNone. We should extend MetaModelica with a real opaque pointer.