Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#3894 closed defect (fixed)

dladdr failed: not available on Windows failed

Reported by: vwaurich Owned by: adrpo
Priority: high Milestone: Future
Component: Code Generation Version:
Keywords: Cc: sjoelund.se, adrpo, wbraun, niklwors

Description

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.

Change History (12)

comment:1 Changed 8 years ago by sjoelund.se

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?

comment:2 Changed 7 years ago by niklwors

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.

comment:3 Changed 7 years ago by sjoelund.se

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

comment:4 Changed 7 years ago by niklwors

  • Cc wbraun niklwors added

comment:5 Changed 7 years ago by vwaurich

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

comment:6 Changed 7 years ago by adrpo

  • Owner changed from lochel to adrpo
  • Status changed from new to accepted

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.

comment:7 Changed 7 years ago by adrpo

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?

comment:8 Changed 7 years ago by adrpo

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.

comment:10 Changed 7 years ago by adrpo

  • Resolution set to fixed
  • Status changed from accepted to closed

Fixed in 057661/OMCompiler.

comment:11 follow-up: Changed 7 years ago by 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)...

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.

comment:12 in reply to: ↑ 11 Changed 7 years ago by adrpo

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.

Note: See TracTickets for help on using tickets.