-
Type:
Bug
-
Status: Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: NGS
-
Labels:
-
Environment:
Windows
-
Sprint:DEV-42-1, DEV-42-2, DEV-42-3, DEV-42-4, DEV-42-5, DEV-42-RELEASE, DEV-43-1, DEV-43-2, DEV-43-3, DEV-43-4, DEV-43-5, DEV-43-RELEASE, DEV-44-1, DEV-44-2, DEV-44-3, DEV-44-4, DEV-44-5, DEV-44-RELEASE, DEV-45-1, DEV-45-2, DEV-45-3, DEV-45-4, DEV-45-5, DEV-45-RELEASE, DEV-46-1, DEV-46-2, DEV-46-3
-
Affect Type:Userdefined
These two crashes in Genome Alignment are of the same nature, their call stack indicates the problem in the same place:
https://api.ugene.net/tools/ugenecrashes/index.php?id=24165
https://api.ugene.net/tools/ugenecrashes/index.php?id=24120
Task tree:
Dna assembly task (Running) 50
-DnaAssemblyMultiTask (Running) 0
--Align short reads (Running) 0
---ReadShortReadsSubTask (Running) 0
---GenomeAlignerFindTask (Running) 100
---LoadIndexTask (Running) -1
Dmitrii Suckhomlinov made a detailed analysis of these falls:
In the TaskSchedulerImpl.cpp file lines 39 to 64 and 1048 to 1052, there is code wrapped in specific ifdefs. This code is processed only if UGENE was compiled by the compiler from Microsoft Visual Studio (we build all our builds on Windows with this compiler, respectively, this is also a Windows-specific piece of code at the same time).
It is only needed for debugging and it only works in the studio. Fursov wrote this code - well, as he wrote it, copied it from here: https://docs.microsoft.com/ru-ru/visualstudio/debugger/how-to-set-a-thread-name-in-native-code? view = vs-2019 It is needed so that when a task is launched in a separate thread, the thread in which it is launched is given the name of this task. This feature helps when debugging. in the debugger, you can switch between different streams and thanks to this thing you can immediately see the streams corresponding to certain tasks (which is especially convenient when there are a lot of tasks). In general, the first two crashes occurred on the RaiseException function (line 60).
it is difficalt to say how to reproduce the problem - this, in principle, can turn out to be problematic, because RaiseException did not find this function and see what is complicated inside it, but fell somewhere in it.
I read the documentation for this feature and there is an indication that in the release it does not make sense at all.
Therefore, I propose to add "ifdef DEBUG" to "ifdef Q_CC_MSVC_NET" (I don’t remember exactly how it is written, but the meaning is clear) so that this code will not be reproduced at all in the release.
- relates to
-
-
- Closed
-