When a user as a project member took ownership of an admins data (with permission), the action initialized ok, then when data trasnsfer started, the core crashed at globus refresh token processing, At least that's the last entry in logs. However, when the core restarted, the task was resumed and completed without issue. Furthermore, after adding debug statements, the core continued crashing - until even more debug with sleeps - then it worked. HOWEVER, after disabling all this logging, the core continued to work without crashing.
A possible factor is that the account initiating the transfer had never logged into the Globus file manager - it could be that Globus was sending an unexpected response (maybe due to latency?) But after core restart, the response was acceptable??? This would imply that the JSON parser has a crash-level bug.
This issue was due to a bug or "limitation" with the very old version of libcurl being used (7.43). Basically it cannot handle multiple TLS connections in one libcurl handle. This has been worked around.
When a user as a project member took ownership of an admins data (with permission), the action initialized ok, then when data trasnsfer started, the core crashed at globus refresh token processing, At least that's the last entry in logs. However, when the core restarted, the task was resumed and completed without issue. Furthermore, after adding debug statements, the core continued crashing - until even more debug with sleeps - then it worked. HOWEVER, after disabling all this logging, the core continued to work without crashing.
A possible factor is that the account initiating the transfer had never logged into the Globus file manager - it could be that Globus was sending an unexpected response (maybe due to latency?) But after core restart, the response was acceptable??? This would imply that the JSON parser has a crash-level bug.
More diagnostics needed.