Testing exception causes segmentation fault.

[jklmnn]

I tried to add a test which tests the exception behaviour. The expected behaviour is a call to ada_raise_exception which prints the message and exits the program cleanly. Yet this isn't happening. I could track the issue down to Create_File_Line_String but not further. When omitting its call in Rcheck_CE_Explicit_Raise and issuing a constant message the behaviour above applies.

[jklmnn]

I added this test on https://github.com/jklmnn/ada-runtime/tree/issue_8.

[treiher]

Could this be related to the secondary stack? Last time we talked about that the current implementation for the POSIX platform which is used for the tests is not correct.

[jklmnn]

I first thought it had to do with the File argument being a null pointer but the segfault also occured when I passed the address of local string. The secondary stack could indeed be a problem. I'll test that. What bothers me is that the secondary stack test doesn't fail (assuming ptr[-1] causes a segfault as well when ptr is allocated by malloc).

[jklmnn]

https://github.com/jklmnn/ada-runtime/commit/c49ba92336d65fec361081d68d1c9cdffec03e73 indeed seems to fix that behaviour by using the upper bound of the memory region. Could you please check if this solution has any drawbacks, especially if the (indeed quite simple) is correct?

[treiher]

I see no drawbacks in the solution.

[jklmnn]

Then I'd say you can squash these three commits and put them on master and we can close the issue.

[treiher]

The error message looks strange:

$ tests/exception/test 
warning: Get_Jmpbuf_Address_Soft not implemented
warning: Set_Jmpbuf_Address_Soft not implemented
Exception raised (256): explicit raise: Sest.adbuf_Address_Soft not implemented

[treiher]

I found the error in Create_File_Line_String and will fix it.

[senier]

@treiher: Can you please briefly describe what issue was an how you solved it? That way, our tickets can help us to learn and avoid similar issues in the future.

[treiher]

@senier The issue was just a stupid beginner mistake, but as you demand a description: An uninitialized fixed-length string was used to store the exception message. The string was at the same location as the log message which was printed before and so initially contained this message. The file name was just written character-per-character into this string, the rest of the string remained unchanged.

Now the implementation determines the length of the file name before declaring a fixed-length string with the correct size and writing the file name into it.