austinp produces only invalid frames on s390x

[helmutg]

On s390x, austinp does not work. The generated non-binary output looks as follows.

P1490406;T0:1490406;:INVALID:;native@113f0fe:<unknown>:0;:55 FRAMES LEFT: 10137
P1490406;T0:1490406;:INVALID:;native@10a032e:<unknown>:0;:55 FRAMES LEFT: 10150
P1490406;T0:1490406;:INVALID:;native@113f69c:<unknown>:0;:55 FRAMES LEFT: 10127
P1490406;T0:1490406;:INVALID:;native@113f252:<unknown>:0;:55 FRAMES LEFT: 10101
P1490406;T0:1490406;:INVALID:;native@113f4be:<unknown>:0;:55 FRAMES LEFT: 10105
P1490406;T0:1490406;:INVALID:;native@113f4de:<unknown>:0;:55 FRAMES LEFT: 10106
P1490406;T0:1490406;:INVALID:;native@113f492:<unknown>:0;:55 FRAMES LEFT: 10086
P1490406;T0:1490406;:INVALID:;native@113f5a8:<unknown>:0;:55 FRAMES LEFT: 10080
P1490406;T0:1490406;:INVALID:;native@10a0356:<unknown>:0;:55 FRAMES LEFT: 10083
P1490406;T0:1490406;:INVALID:;native@1141212:<unknown>:0;:55 FRAMES LEFT: 10116
P1490406;T0:1490406;:INVALID:;native@113dea4:<unknown>:0;:55 FRAMES LEFT: 10113

I traced austin, to see where those frames would be emitted and it is https://github.com/P403n1x87/austin/blob/master/src/py_thread.c#L999.

The syslog repeats the following.

Circular frame reference detected
Invalid resolved Python stack
Stack mismatch: left with 55 Python frames after interleaving
Invalid thread

These messages correspond to the following code lines:

• https://github.com/P403n1x87/austin/blob/master/src/py_thread.c#L442
• https://github.com/P403n1x87/austin/blob/master/src/py_thread.c#L977
• https://github.com/P403n1x87/austin/blob/master/src/py_thread.c#L1016
• https://github.com/P403n1x87/austin/blob/master/src/py_thread.c#L1017

It's not clear to me where to go from here. Figuring out what's going on here likely requires deeper knowledge of austinp than I have. Meanwhile austin just works. I'm not sure whether there are that many s390x users.

[P403n1x87]

Would it be possible to skip the build of austinp for this architecture? It doesn't sound like there would be a lot of value in trying to figure this one out? WDYT?

[helmutg]

I have seen similar symptoms for more architectures such as armhf (once fixing #268). It's not simply a big endian issue. I suspect there is a deeper problem beneath, but then I also agree with it not being urgent. How about just leaving the issue open and collecting more information (e.g. the bit that it also is observable on armhf) for a while?