#946 Subsequent download fails while system monitoring is active

[T. Ellinger]

Environment:

• Linux (Ubuntu 14.04 LTS x64)
• FORTE V1.6
• 4DIAC-IDE V1.6

Steps to reproduce:

1. Deploy Xplus3 application to according fbrt and forte instances
2. Monitor the system
3. Change application (e.g. change F_ADD.IN2 to literal INT#4) and save changes
4. Download changes to MICROCONTROLLER

-->Message Box "Create Ressource Instance "CALC" failed" (see attachment) appears.

-->Stop and relaunch forte results in forte error "Adress already in use", I assume this is caused by inproper shutdown of forte.

[Zoitl Alois]

I tried to reproduce the issue. I get a different but also wrong behavior.

The problem is that the FORTE remote management interface only accepts one connection at the time. Currently monitoring and deployment can not use the same connection in the IDE. Therefore the fastest workaround here is to stop monitoring perform deployment tasks and then re-enable monitoring. The selected monitoring variables should reaper.

However FORTE shutdown should free the resources. Is there any output in FORTE's console which gives a hint that something is wrong?

[T. Ellinger]

Thank you for trying and clarification. Mostly I used the workaround you mentioned. Though, sometimes I forgot to switch of monitoring which lead to FORTE hanging up or crashing.

I started FORTE from shell and did the same steps. After IDE shows error, FORTE seems to stop working (no mgmt communication possible) and no further output. When I terminate FORTE by SIGTERM using <ctrl+c> I get following output:</ctrl+c>

DEBUG: T#notime: CSocketBaseLayer::closeConnection()
DEBUG: T#notime: CSocketBaseLayer::closeConnection()
INFO: T#notime: Connection closed by peer
TRACE: T#notime: Starting ECTRACE: T#notime: CEventChainExecutionThread::startEventChain
Segmentation fault

Improvement idea

There may be a possible improvement for IDE to avoid this issue:

• Before download is performed, IDE could check if monitoring is currently active and stops monitoring first.
• Then it performs download to FORTE as usual.
• After that, IDE may remember that monitoring was active prior the download and therefore activates monitoring again (see attachment)

[Zoitl Alois]

Today I spent more time on this issue. I could at least find a very nasty issue in FORTE the caused part of the problem. Unfortunately it is so that the listen call used in the server does not limit the amount of clients that are allowed to connect. Therefore a second connection attempt was allowed and unexpectedly handled wrong. This caused the FORTE to be not accessibly anymore. In cset [forte:f50eee] a fix for this problem can be found. With this fix it is now possible to recover from your problem when you forgot to deactivate the monitoring.

Your solution for handling it in the IDE is definitely the best approach. However currently the deployment and the monitoring are coming from two different completely decoupled plug-ins. Therefore the obht don't know from each other. I think we need to think a little bit more how to solve this without introducing to much dependencies. Also it would be good if both plugins would use the same code for interacting with the devices, which is currently also not the case.

[T. Ellinger]

Thank you for spending your time on this issue. I confirm that it is now fixed.

I tried cset [forte:f50eee] and it indeed solves the hangup/crash issue. Now when I perform the test, IDE drops message box "Major download error" and I am able to recover and deactivate monitoring prior to download.

Perhaps IDE could be improved to give a more convincing message box with a hint (e.g. "Ensure monitoring is switched off")

Thank you for clarifying and sharing your thoughts about my proposal of IDE's handling. Maybe it is helpful for improvement in further versions. Do you intend to backlog this as a feature request?

[Zoitl Alois]

The reason I haven't closed this issue so far is that I didn't want to loose the information on the needed improvement in the IDE here. As we have now three things in this issue I think it would be better to close this and create two new feature requests. Could you do this?

[T. Ellinger]

Yes, I'd be glad to. I agree that it makes more sense to split-off remaining things into seperate feature requests.

Here they are:

• [#948] Automatically disable/re-enable monitoring within subsequent download
• [#949] Give a more convincing message when monitoring is active and user tries to perform download

[Zoitl Alois]

Thanks. I'll close this issue for now.