DCD stops working if some thread is created after instantiation of ModuleCache #407
Comments
|
autocomplete.d |
ghost
added
the
|
It doesn't look like a trivial bug. Can you provide a small DUB project that reproduces it simply by running |
|
Ok. I need some time to do it. |
|
Or instead of a project a single module with a DUB SDL header. This system allows to put dependencies too. |
|
Created sample project to reproduce issue: https://github.com/buggins/dcdtest Test results: Performing "debug" build using dmd for x86. int main(string[] args) { } position: 59 |
|
Test:
Windows 7 |
|
Thanks, i can see the problem on linux x86-64 too. |
|
After a GDB session, i've found something interesting in dsymbol.scope_.d, line 131 inout(DSymbol)*[] getSymbolsByName(istring name) inout
{
import std.array : array, appender;
import std.algorithm.iteration : map;
DSymbol s = DSymbol(name);
auto er = _symbols.equalRange(SymbolOwnership(&s));
if (!er.empty)
return cast(typeof(return)) array(er.map!(a => a.ptr));
So far it looks like it's |
|
Thanks! Will try to investigate it further. |
|
I see strange behavior. 2017-08-15T09:53:45.056:deps\DCD\dsymbol\src\dsymbol\scope_.d:getSymbolsByNameAndCursor:193 calling getSymbolsByName long ptr=650B6EA // new thread is created 2017-08-15T09:54:57.462:deps\DCD\dsymbol\src\dsymbol\scope_.d:getSymbolsByNameAndCursor:193 calling getSymbolsByName long ptr=10EBA0EA Cannot reproduce it by adding test string interning in sample app. |
|
Added check for improperly interned strings to getSymbolsByName: Before thread creation there are no warnings. After thread creation there are some non-interned strings detected: stack traces look like Tried to modify source file for which symbol lookup is requested. I see warnings for built in types: long, ulong, float, double, int... |
|
Update: Issue is probably caused by dsymbol.builtin.names constants. I've modified example to dump builtinTypeNames[0..5] before, inside and after new thread. When new thread is created, dsymbol.builtin.names constants will be changed to allocated in new thread string cache. Updated code: |
|
Following hack does not work if some thread is already created before DCD thread. dsymbol.builtin.names: Removing of immutable breaks Another dirty hack works ok: lockBuiltinNames() has to be called from thread which will be used for DCD. |
|
Yes you've found it. without the |
|
BTW i've tested without the hack, here i still have the first version of the test case. It means that just a PR in DSymbol can fix the issue. |
|
If removing of immutable is ok, I could create PR. |
|
In names.d replace |
|
Will const be thread locals? |
|
no, sorry it was a mistake to sat that. don't put const. |
|
By the way i've verified and the changes don't break DCD so you can really make the PR now. |
|
Created PR. |
|
not much. 1 hour max because the bot at code.dlang.org has to detect the tag. |
|
Are you going to release new label of DCD with updated DSymbol? |
|
do you need one ? I can certainly push an alpha label. By the way i need review + approval for the DCD PR. |
|
Trying to resolve it by adding DlangIDE dependency Seems working for me. Thank you a lot for your help! |
fix #407 - DCD stops working if some thread is created after instanti…
|
I've set 0.9.1 because there was a few things anyway since 0.9.0 |
I'm using DCD as a library in DlangIDE.
All DCD calls are made from separate thread.
DCD works ok until some thread is created (e.g. to invoke DUB for building).
After this operation DCD stops working correctly and can locate symbols only from current source file.
Root cause:
If some another thread is created after DCD thread instantiated ModuleCache, DCD is not able to process goToDefinition for symbol and other functions if they are related to other modules than current source file.
Probably, it's related to ModuleCache and/or allocators.
Steps to reproduce:
After creation of ModuleCache, start some thread and wait until it's finished.
The text was updated successfully, but these errors were encountered: