r7182 introduced what was thought to be a fix to a situation where unsuccessful attempts to register !NatPunchAffixes would cause the Affix stack (and the number of advertise threads, and memory usage) to grow beyond bounds. The logic in that release unfortunately pop()s from the Affix stack also in situations where the suspected-to-be-misbehaving !NatPunchAffix was never pushed, resulting in (non-fatal) errors like
1396452890.74:PID-20244:[Found Listenforconnection had exception: The stack is empty. We cannot pop() further Affixes.
1396452890.74:PID-20244:[ERROR](ERROR]): when calling listenforconnection for the connection_handler: The stack is empty. We cannot pop() further Affixes.
1396452890.74:PID-20244:Traceback (most recent call last):
File "nmmain.py", line 356, in start_accepter
File "/home/administrator/seattle/seattle_repy/affixstackinterface", line 207, in listenforconnection
File "coordinationaffix", line 135, in listenforconnection
File "legacyaffix", line 138, in listenforconnection
File "coordinationaffix", line 135, in listenforconnection
File "natdecideraffix", line 210, in listenforconnection
File "baseaffix", line 195, in pop
AffixStackError: The stack is empty. We cannot pop() further Affixes.
Attached is my patch to attempt pop() ping the !NatPunchAffix only when I'm sure it was actually push() ed before. Please review and commit (if OK).
Thanks go to Jakub Dalek for sharing his nodemanager log to aid debugging!
r7182 introduced what was thought to be a fix to a situation where unsuccessful attempts to register !NatPunchAffixes would cause the Affix stack (and the number of advertise threads, and memory usage) to grow beyond bounds. The logic in that release unfortunately
pop()
s from the Affix stack also in situations where the suspected-to-be-misbehaving !NatPunchAffix was never pushed, resulting in (non-fatal) errors likeAttached is my patch to attempt pop() ping the !NatPunchAffix only when I'm sure it was actually push() ed before. Please review and commit (if OK).
Thanks go to Jakub Dalek for sharing his nodemanager log to aid debugging!