Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Greenlet issues on Solaris sparc 64-bit #431

Open
sfv880 opened this issue Oct 22, 2024 · 0 comments
Open

Greenlet issues on Solaris sparc 64-bit #431

sfv880 opened this issue Oct 22, 2024 · 0 comments

Comments

@sfv880
Copy link

sfv880 commented Oct 22, 2024

Hello,

I hope you are well!

We use Greenlet 3.0.3 and 0.4.15 on Solaris 11.4 sparc 64-bit platform and in some cases it failed with:

  • SIGBUS (Bus Error) - access to unaligned memory address
status: process terminated by SIGBUS (Bus Error), addr=4f00e0070bf0000a
python:core> $c
_greenlet.cpython-311.so`slp_restore_state_trampoline+0x74(ffffffff7fff8f71, 0, 0, ffffffffffffffff, ffffffff7dfdf470, 
ffffffff7f227060)
_greenlet.cpython-311.so`slp_switch+0x18(ffffffffffffffff, 7ffface0da78, ffffffff7f5a06c0, 8, ffffffff7fff97f0, 
ffffffff7fff8f71)
_greenlet.cpython-311.so`_ZN8greenlet8Greenlet13g_switchstackEv+0x17c(ffffffff7fff9998, ffffffff7dfdf470, 
ffffffff7fff99a8, ffffffff7e166de0, ffffffff7f227030, 7fffa631a2b8)
  • SIGSEGV (Segmentation Fault) - access to unmapped memory address
status: process terminated by SIGSEGV (Segmentation Fault), addr=18
python:core> $c
greenlet-0.4.15-py3.8-sola`slp_save_state+0x50(ffffffff7fff3f31, 0, ffffffff7e9e8c80, 7fffb0d069a8, ffffffffffffffff, 0)
greenlet-0.4.15-py3.8-sola`slp_switch+0x18(ffffffffffffffff, 0, 20, 100106140, 0, ffffffff7fff3f31)
greenlet-0.4.15-py3.8-sola`g_switchstack+0x54(ffffffff7f272540, ffffffff7fff49d8, e60, 0, 7fffb0d06998, ffffffff7d2c2e10)
greenlet-0.4.15-py3.8-sola`g_switch+0x12c(ffffffff7e961540, ffffffff7fff4948, 7fffb0d069a8, 7fffb0d06988, 7fffb0d06998, 
7fffb0d06990)

But in all cases it happened after the slp_switch call.
I read the src/greenlet/platform/switch_sparc_sun_gcc.h source code and I have a questions:

#define STACK_MAGIC 0

Is it correct value for the sparcv9 platform ?
According to the https://docs.oracle.com/cd/E37838_01/html/E66175/advanced-2.html

6.1 SPARC V9 ABI Features
6.1.1 Stack Bias

An important feature of the SPARC V9 ABI for developers is the stack bias.
For 64-bit SPARC programs, a stack bias of 2047 bytes must be added to both
the frame pointer and the stack pointer to get to the actual data of the stack frame. 
  • I tried to build Greenlet 3.0.3 without optimization (using -O0) and in this case it constantly failed on BUS error:
creating build/temp.solaris-2.11-sun4v.64bit-3.11/src/greenlet
gcc -fPIC -m64 -pthread -c src/greenlet/greenlet.cpp -o build/temp.solaris-2.11-sun4v.64bit-3.11/src/greenlet/greenlet.o -O0
...
# python3 -m unittest discover -v greenlet.tests
test_break_ctxvars (greenlet.tests.test_contextvars.ContextVarsTests.test_break_ctxvars) ...
Bus Error               (core dumped) python3 -m unittest discover -v greenlet.tests
...
status: process terminated by SIGBUS (Bus Error), addr=fffffd2621cb0ce1
python3.11:core> $c
_greenlet.cpython-311.so`_ZN8greenlet10StackState18copy_heap_to_stackERKS0_+0x60(7feae8c1f4530, 7feae8d1693e0, 
7feae8d1693e0, 0, 0, 0)
_greenlet.cpython-311.so`_ZN8greenlet8Greenlet17slp_restore_stateEv+0x68(7feae8c1f4500, fffffd2621cb0621, 7feae8f4306c0, 
8, 7feae8ed0d978, 7feae8c1f4530)
_greenlet.cpython-311.so`slp_restore_state_trampoline+0x2c(fffffd2621cb0ce1, 7feae893fb100, 7feae8f4306c0, 8, 
7feae89491840, fffffd2621cb1598)
_greenlet.cpython-311.so`slp_switch+0x24(0, 7feae8ed0d978, 7feae8f4306c0, 8, 0, 7feae8c1344b0)
_greenlet.cpython-311.so`_ZN8greenlet8Greenlet13g_switchstackEv+0x204(fffffd2621cb1910, 7feae8d1693b0, 7feae8c1f4530, 8, 
7feae89480180, 7feae8c1344b0)
...

Please help me debug this issue - how can I check/validate the correct value of the Greenlet stack ?

Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant