gethostbyname test FAIL with NUCLEO_F746ZG and IAR

[jeromecoutant]

Description

mbed test -m NUCLEO_F746ZG -t iar -vv -n tests-netsocket-gethostbyname

=> test is often FAIL
Target can't connect during DHCP procedure...

Test is OK with ARM and GCC

Target
NUCLEO_F746ZG

Toolchain
IAR

[0xc0170]

To be seen here #5597 (the last 2 ci test run)

@kegilbert @studavekar I haven't seen it logged yet, was this known prior this report?

[kegilbert]

@0xc0170 I had seen that error on the linked PR but thought it was due to the PR itself. I'll look into it on our end.

[kegilbert]

I'm able to reproduce this locally as well on IAR.

[0xc0170]

@kegilbert Thanks, I noticed that this is now real on master.

@SeppoTakalo @mikaleppanen @kjbracey-arm Can you help with this one?

[kjbracey]

Is this really specifically only the gethostbyname test failing? The failure appears to be an assert on return from the "connect" - getting a DHCP failure. So nothing to do with the gethostbyname bit.

What appears to be distinct about gethostbyname compared to other tests is that it does its connect in the test setup stage, rather than in a test case. That's presumably a clue. Not familiar enough with the test frame work to interpret the clue though.

[0xc0170]

Thanks Kevin. It's just that one test and only one toolchain, and seldomly appears in our test logs.

What appears to be distinct about gethostbyname compared to other tests is that it does its connect in the test setup stage, rather than in a test case. That's presumably a clue. Not familiar enough with the test frame work to interpret the clue though.

@jeromecoutant Can we look at this particular, if that would help?

Has anyone been able to reproduce this?

[jeromecoutant]

Test seems OK in morph test results #5576
http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5576/473

[kegilbert]

The error seems to be fairly intermittent, I was unable to locally reproduce earlier this week but saw it crop up again in a CI run the next day. Trying to look more into it now.

[jarlamsa]

I was able to reproduce this locally, seems like test-case issue, I am preparing a fix for this.

[jarlamsa]

Made a PR: #5689
I am not entirely sure why the preprocessor macro seems to cause this to happen

[kjbracey]

Okay, seems we've got an environment where we can get 100% failure with the default develop build, but it passes with a debug build. That preprocessor macro change in #5689 must just be one example of a memory layout change that avoids the problem.

I guess the change in #5689 is that we are adding 1 pointer in RAM - the const char *, shifting everything by 4 bytes. (If it were const char * const, the pointer would be in ROM, so maybe wouldn't have changed anything? Might be worth trying.)

I think tomorrow's job is to JTAG debug the failing develop image to try to spot some corrupted memory stopping the connect from completing.

I am reminded of #4686 - the best guess we currently have there is that someone is corrupting a static variable in the HAL's serial code. Different platform and compiler, but maybe could be caused by the same generic memory corruption bug?