SE_UpdateOSIGroundTruth causes AccessViolation

[cfschaller]

Hi Emil,

sorry to bother you with this, but I hope you may be able to help me figure this one out:

As you may be aware we're successfully using a headless esmini to play OpenSCENARIOs within our C#/Unity application. As we recently updated to the newest version, I saw that there is also the option to write OSI data now. I went ahead and wanted to try the new functionality (following your HelloWorld example), so the experimental workflow now looks like this

• SE_Init <-- successful
• SE_EnableOSIFile <-- successful
• Initial SE_UpdateOSIGroundTruth <-- causes System.AccessViolationException "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
• Repeated: SE_StepDT + SE_UpdateOSIGroundTruth
• SE_DisableOSIFile
• SE_Close

I tried this with the most recently released esminiLib.dll on Windows as I though D_OSI was enabled by default.
Do I need to build a custom version anyways or is it necessary to place the osi-dlls next to the esminiLib?

Looking forward to hearing from you and thanks in advance,
Christoph

[eknabevcc]

Can't reproduce. Based on code-examples/osi-groundtruth/osi-groundtruth.cpp I just added on line 14:
SE_EnableOSIFile("kalle.osi");
And it seems to work OK for me. Is this similar to your flow? What could then be different from your setup? I'd like to find the issue. Could you provide more details. E.g.

1. The source code (if sensitive maybe you can just extract the bare minimum to reproduce?)
2. Exact version of the DLL your using? You're right, the bin releases are all compiled with OSI support.

I hope we can catch this bug or whatever root cause it may be! (yes, it can still be a bug even if it's not showing its face always - but without being able to reproduce it's really hard to investigate)

[cfschaller]

Hi Emil,
just wanted to get back to you with a short update on this one.

I've created a minimal example and narrowed the problem down to:

• if I use one of the esmini examples, e.g. cut-in.xosc, it works
• with some other (external) scenarios I get the above-mentioned AccessViolation. However, the same scenarios will work fine if not using OSI (i.e. just playing and using the ScenarioObjectState struct)

I am now steadily reducing the critical examples in order to find which OpenSCENARIO element causes this and will get back to you as soon as I know more.

[cfschaller]

Hi Emil,

I finally found the time to look into the issue it again.
The problem seems to be the underlying OpenDRIVE. There are no problems using "simple" tracks such as e6mini.xodr. However, when using more complex maps, the aforementioned AccessViolation occurs when trying to use OSI while there are no problems using the ScenarioObjectState.

Attached, please find the scenario cut-in_Town01.zip that causes the AccessViolation for me. The underlying OpenDRIVE Town01.xodr is part of the CARLA simulator and can be found here:
https://github.com/carla-simulator/map/blob/master/ad_map_access/tests/test_files/Town01.xodr

Could you please check whether you can reproduce the bug with that scenario/track?
Otherwise, I can also provide my minimal code example (but it should be identical to your code, just in C#). I tested using esmini release 2.19.1.

Thanks again,
Christoph

[eknabevcc]

Thanks for providing the files! I sure helped a lot.

The crash is a result of deferring non initialized OSI data during intersection processing. We have now fixed (commit c69c3a6) symptom. But we're a bit unsure why the specific data was not initialized/populated. We haven't encountered this issue before, so this is a good finding!

It would be appreciated if you could test again with the fix and report if it works OK or if you see some (other) issues.

The fix will be included in next release. Let us know if you need/want one asap.

[cfschaller]

Hi Emil,

thanks for the fix - I just build manually and checked with a scenario on Town01.xodr. It worked. :)

However, the problem still exists on other (more complex?) maps, e.g. Town03 (https://github.com/carla-simulator/map/blob/master/ad_map_access/tests/test_files/Town03.xodr). If necessary, I can also provide a simple scenario on that map.
Can you please check whether you see the same behavior?

[eknabevcc]

Thanks again for pointing out further problems. These roads are good smoke tests of some OSI handling in road manager :)

Commit 6e7e0a2 hopefully close a few bugs, again caused by dereferencing undefined data. Root cause is still unclear (OpenDRIVE and/or code), but anyway crash should be avoided.

Please try again. And please report any further issues.

[cfschaller]

Hi Emil,

thanks again - I just tested the new version and now most (~90%) of the XODRs that I have access to are working.
Problems still seem to exist for (complex?) highway tracks - unfortunately I cannot share those here. :/
However, I found one more XODR on the web that causes the issue:
testComplexXodr.zip

Can you please check again (sorry for all the trouble..)?
In the meantime, I will try to see if I can share one of the other aforementioned maps with you.

[eknabevcc]

Thanks for further findings on this!
A few more checks have been added in branch fix_rm_osi_issues.
Would it be possible for you to test your challenging odr's with that?

[cfschaller]

Hi Emil,

just wanted to report back - no more AccessViolations with the new release, so I am closing this one. Once again, thanks for the great work in resolving those issues!