|Anonymous | Login | Signup for a new account||2021-02-27 16:56 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007900||opensim||[REGION] OpenSim Core||public||2016-05-05 07:51||2019-02-06 11:30|
|Platform||Operating System||Operating System Version|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0007900: Crash due to setting Thread.name after thread start. [PATCH]|
|Description||Behaviour pronounced on Linux kernels above 3.10 or hangs within console input monitoring during MS Windows Visual Studio debug sessions.|
MSDN documentation states:
'This property is write-once. Because the default value of a thread's Name property is null, you can determine whether a name has already been explicitly assigned to the thread by comparing it with null.'
It does not explicitly state that the name can be set after the thread has started.
Applies to both Robust and Simulator.
The patch provided does not change functionality, only applies caution as to the unpredictable nature when the name is set after thread start.
|Steps To Reproduce||Operate OpenSim simulator or robust on Linux kernels above 3.10|
Operate OpenSim simulator debug session within MS Windows Visual Studio.
|Additional Information||Observing runtime code it appears that thread management memory is allocated during thread class instantiation and is therefore vulnerable to corruption should an excessive name length be set after this time.|
|Tags||No tags attached.|
|Git Revision or version number||all current development and releases|
|Run Mode||Grid (1 Region per Sim)|
|Environment||Mono / Windows|
|Attached Files||0001-Fix-crash-due-to-setting-Thread.name-after-thread-st.patch [^] (2,123 bytes) 2016-05-05 07:51 [Show Content]|
Having successfully run the test patch suggested in http://opensimulator.org/mantis/view.php?id=7895 [^] and observed that it eliminated the crashing, I'm now running this formal patch, instead.
I'll run it for a couple of days and then I'll report back.
|I have not had any crashes while running this patch.|
|Making sure someone notices that Zadark added a patch here ...|
[17:43] <cia-opensim> opensim: zadarkportal * r97a471cb3570 / (2 files in 2 dirs):
[17:43] <cia-opensim> Fix crash due to setting Thread.name after thread start.
[17:43] <cia-opensim> Signed-off-by: Diva Canto <email@example.com>
Please report back if this makes things work better.
Scooby Scorfield (reporter)
|I have tried applying this fix twice, but unfortunately I am still getting the crashes. I'm running CentOS 7 x64 with a 3.10 kernel.|
As stated the patch fixes crashes due to thread naming.
You can verify by observing stacktrace report includes
Debug info from gdb:
I was experiencing crashes of various idle regions, daily, until applying this patch and this is what I'm running it on:
[ste@os00 ~]$ cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
[ste@os00 ~]$ uname -a
Linux os00 3.10.0-327.13.1.el7.x86_64 0000001 SMP Thu Mar 31 16:04:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
I'm not sure why it isn't working for Scooby, but it certainly is for me.
Scooby Scorfield (reporter)
Just to confirm, this is the output I'm seeing:-
While it relates to 'libpthread.so.0', I'm not seeing 'pthread_setname_np'
I don't know enough about it to know if this is the same issue?
@scooby. Thread naming appears not to be contributing to your issue.
As Opensim makes extensive use of threads stacktrace includes libpthread.so.0
To progress with your issue create a new mantis documenting system configuration history and usage.
Author: Roger Kirkman <firstname.lastname@example.org>
Date: Thu May 5 15:21:15 2016 +0100
Fix crash due to setting Thread.name after thread start.
Signed-off-by: Diva Canto <email@example.com>
|Marked as Resolved but never closed, can be reopened if needed.|
|2016-05-05 07:51||zadark||New Issue|
|2016-05-05 07:51||zadark||File Added: 0001-Fix-crash-due-to-setting-Thread.name-after-thread-st.patch|
|2016-05-07 09:11||smxy||Note Added: 0030278|
|2016-05-11 14:04||smxy||Note Added: 0030298|
|2016-05-11 16:42||smxy||Note Added: 0030299|
|2016-05-11 16:42||smxy||Status||new => patch included|
|2016-05-11 16:44||smxy||Relationship added||related to 0007895|
|2016-05-12 18:00||Diva||Note Added: 0030301|
|2016-05-15 01:49||Scooby Scorfield||Note Added: 0030314|
|2016-05-15 04:27||zadark||Note Added: 0030315|
|2016-05-15 09:29||smxy||Note Added: 0030316|
|2016-05-15 10:01||Scooby Scorfield||Note Added: 0030317|
|2016-05-15 15:27||zadark||Note Added: 0030318|
|2016-05-17 08:26||kcozens||Note Added: 0030331|
|2016-05-17 08:27||kcozens||Status||patch included => resolved|
|2016-05-17 08:27||kcozens||Resolution||open => fixed|
|2016-05-17 08:27||kcozens||Assigned To||=> kcozens|
|2016-05-17 08:27||kcozens||Assigned To||kcozens =>|
|2016-05-17 08:29||kcozens||Resolution||fixed => open|
|2016-05-17 09:16||zadark||Relationship added||related to 0007384|
|2019-02-06 11:30||BillBlight||Note Added: 0034538|
|2019-02-06 11:30||BillBlight||Status||resolved => closed|
|Copyright © 2000 - 2012 MantisBT Group|