Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Code completion using LSP and clangd

<< < (67/92) > >>

ollydbg:
Today, I got a crash when I'm editing in C::B, see the call stack here, (from the codeblocks.RPT file)


--- Code: ---Error occurred on Sunday, November 12, 2023 at 11:26:58.

codeblocks.exe caused an Access Violation at location 00007FF870B9D924 in module clangd_client.dll Reading from location FFFFFFFFFFFFFFFF.

AddrPC           Params
00007FF870B9D924 000002A835C963F0 000002A83BBBD890 000002A836EDF8A0  clangd_client.dll!ClassBrowserBuilderThread::AddMembersOf+0x2cc  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 921]
00007FF870B9AABF 000002A835C963F0 0000000000000000 0000000000000000  clangd_client.dll!ClassBrowserBuilderThread::SelectGUIItem+0x2db  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 472]
00007FF870B99A7D 000002A835C963F0 0000000000000001 0000000000000000  clangd_client.dll!ClassBrowserBuilderThread::Entry+0x99  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 309]
00007FF8782ECFBD 0000000000000000 000002A83653DCF0 000002A835C963F0  wxmsw32u_gcc_cb.dll!wxThreadInternal::DoThreadStart+0x64d
00007FF8782ED113 000002A83653C8D0 0000000000000000 000002A83653C8D0  wxmsw32u_gcc_cb.dll!wxThreadInternal::WinThreadStart+0x43
00007FF8CC66AF5A 00007FF8CC6C06D0 000002A83653C8D0 0000000000000000  msvcrt.dll!_beginthreadex+0x12a
00007FF8CC66B02C 0000000000000000 0000000000000000 0000000000000000  msvcrt.dll!_endthreadex+0xac
00007FF8CC0F7344 0000000000000000 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF8CD5C26B1 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x21

--- End code ---

It looks like a crash from the symbol tree building thread.

I'm using the clangd_client.dll without strip the debug information. And I'm using the rev 13384, I have some own patches, but my patches don't touch the symbol tree and thread handling related code.

Thanks.

Pecan:

--- Quote from: ollydbg on November 12, 2023, 04:32:47 am ---Today, I got a crash when I'm editing in C::B, see the call stack here, (from the codeblocks.RPT file)


--- Code: ---Error occurred on Sunday, November 12, 2023 at 11:26:58.

codeblocks.exe caused an Access Violation at location 00007FF870B9D924 in module clangd_client.dll Reading from location FFFFFFFFFFFFFFFF.

AddrPC           Params
00007FF870B9D924 000002A835C963F0 000002A83BBBD890 000002A836EDF8A0  clangd_client.dll!ClassBrowserBuilderThread::AddMembersOf+0x2cc  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 921]
00007FF870B9AABF 000002A835C963F0 0000000000000000 0000000000000000  clangd_client.dll!ClassBrowserBuilderThread::SelectGUIItem+0x2db  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 472]
00007FF870B99A7D 000002A835C963F0 0000000000000001 0000000000000000  clangd_client.dll!ClassBrowserBuilderThread::Entry+0x99  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 309]
00007FF8782ECFBD 0000000000000000 000002A83653DCF0 000002A835C963F0  wxmsw32u_gcc_cb.dll!wxThreadInternal::DoThreadStart+0x64d
00007FF8782ED113 000002A83653C8D0 0000000000000000 000002A83653C8D0  wxmsw32u_gcc_cb.dll!wxThreadInternal::WinThreadStart+0x43
00007FF8CC66AF5A 00007FF8CC6C06D0 000002A83653C8D0 0000000000000000  msvcrt.dll!_beginthreadex+0x12a
00007FF8CC66B02C 0000000000000000 0000000000000000 0000000000000000  msvcrt.dll!_endthreadex+0xac
00007FF8CC0F7344 0000000000000000 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF8CD5C26B1 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x21

--- End code ---

It looks like a crash from the symbol tree building thread.

I'm using the clangd_client.dll without strip the debug information. And I'm using the rev 13384, I have some own patches, but my patches don't touch the symbol tree and thread handling related code.

Thanks.

--- End quote ---

Update to at least rev 13390.
I think this is already fixed.
Thanks for the report.

christo:
Hi Pecan, I'm using a custom compiler for some projects. It is not recognised by clangd. If I change the code as below, it works fine and standard headers are parsed properly.


--- Code: ---Index: src/plugins/contrib/clangd_client/src/LSPclient/client.cpp
===================================================================
--- src/plugins/contrib/clangd_client/src/LSPclient/client.cpp (revision 13394)
+++ src/plugins/contrib/clangd_client/src/LSPclient/client.cpp (working copy)
@@ -427,11 +427,9 @@
     wxString masterPath = pCompiler ? pCompiler->GetMasterPath() : "";
 
     // get the first char of executable name from the compiler toolchain
-    CompilerPrograms toolchain = pCompiler->GetPrograms();
-    wxString toolchainCPP = toolchain.CPP.Length() ? wxString(toolchain.CPP[0]) : "";
+    const CompilerPrograms& toolchain = pCompiler->GetPrograms();
     // " --query-driver=f:\\usr\\MinGW810_64seh\\**\\g*"
-    wxString queryDriver = masterPath + fileSep + "**" + fileSep + toolchainCPP + "*";
-    if (not platform::windows) queryDriver.Replace("\\","/");
+    wxString queryDriver = masterPath + fileSep + "bin" + fileSep + toolchain.CPP;
 
     wxString pgmExec = clangd_Dir + fileSep + clangdexe;
     QuoteStringIfNeeded(pgmExec);


--- End code ---
As per the compiler settings, compiler binary should be present in <compiler path>/bin/ , so above change looks fine.  But I'm afraid it could break some cases achieved by the original logic.  Could you please help? I use Code::Blocks svn trunk on Ubuntu 18.04 wxwidgets 3.0 .

Thanks, Christo


ollydbg:

--- Quote from: Pecan on November 12, 2023, 06:53:39 am ---Update to at least rev 13390.
I think this is already fixed.
Thanks for the report.

--- End quote ---

I think I still catch a crash bug several minutes ago, see the call stack below, I'm using the latest rev13394.


--- Code: ---Error occurred on Tuesday, November 14, 2023 at 18:38:00.

codeblocks.exe caused an Access Violation at location 00007FF8733ED844 in module clangd_client.dll Reading from location FFFFFFFFFFFFFFFF.

AddrPC           Params
00007FF8733ED844 000001B980D42BB0 000001B98611E480 000001B98175AC10  clangd_client.dll!ClassBrowserBuilderThread::AddMembersOf+0x2cc  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 921]
00007FF8733EA9DF 000001B980D42BB0 0000000000000000 0000000000000000  clangd_client.dll!ClassBrowserBuilderThread::SelectGUIItem+0x2db  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 472]
00007FF8733E999D 000001B980D42BB0 0000000000000001 0000000000000000  clangd_client.dll!ClassBrowserBuilderThread::Entry+0x99  [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 309]
00007FF876B7CFBD 0000000000000000 000001B980C88330 000001B980D42BB0  wxmsw32u_gcc_cb.dll!wxThreadInternal::DoThreadStart+0x64d
00007FF876B7D113 000001B980C877B0 0000000000000000 000001B980C877B0  wxmsw32u_gcc_cb.dll!wxThreadInternal::WinThreadStart+0x43
00007FF8CC66AF5A 00007FF8CC6C06D0 000001B980C877B0 0000000000000000  msvcrt.dll!_beginthreadex+0x12a
00007FF8CC66B02C 0000000000000000 0000000000000000 0000000000000000  msvcrt.dll!_endthreadex+0xac
00007FF8CC0F7344 0000000000000000 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF8CD5C26B1 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x21

--- End code ---

EDIT:

The line 921 is at this line:


--- Code: ---    if (data)
    {
        switch (data->m_SpecialFolder) // line 921 **************************
        {
            case sfGFuncs  : AddChildrenOf(tree, node, -1, tkFunction, false); break;
            case sfGVars   : AddChildrenOf(tree, node, -1, tkVariable, false); break;
            case sfPreproc : AddChildrenOf(tree, node, -1, tkMacroDef, false); break;
            case sfTypedef : AddChildrenOf(tree, node, -1, tkTypedef,  false); break;
            case sfMacro   : AddChildrenOf(tree, node, -1, tkMacroUse, false); break;
            case sfToken:
            {

--- End code ---

Pecan:

--- Quote from: christo on November 13, 2023, 07:32:33 pm ---Hi Pecan, I'm using a custom compiler for some projects. It is not recognised by clangd. If I change the code as below, it works fine and standard headers are parsed properly.


--- Code: ---Index: src/plugins/contrib/clangd_client/src/LSPclient/client.cpp
===================================================================
--- src/plugins/contrib/clangd_client/src/LSPclient/client.cpp (revision 13394)
+++ src/plugins/contrib/clangd_client/src/LSPclient/client.cpp (working copy)
@@ -427,11 +427,9 @@
     wxString masterPath = pCompiler ? pCompiler->GetMasterPath() : "";
 
     // get the first char of executable name from the compiler toolchain
-    CompilerPrograms toolchain = pCompiler->GetPrograms();
-    wxString toolchainCPP = toolchain.CPP.Length() ? wxString(toolchain.CPP[0]) : "";
+    const CompilerPrograms& toolchain = pCompiler->GetPrograms();
     // " --query-driver=f:\\usr\\MinGW810_64seh\\**\\g*"
-    wxString queryDriver = masterPath + fileSep + "**" + fileSep + toolchainCPP + "*";
-    if (not platform::windows) queryDriver.Replace("\\","/");
+    wxString queryDriver = masterPath + fileSep + "bin" + fileSep + toolchain.CPP;
 
     wxString pgmExec = clangd_Dir + fileSep + clangdexe;
     QuoteStringIfNeeded(pgmExec);


--- End code ---
As per the compiler settings, compiler binary should be present in <compiler path>/bin/ , so above change looks fine.  But I'm afraid it could break some cases achieved by the original logic.  Could you please help? I use Code::Blocks svn trunk on Ubuntu 18.04 wxwidgets 3.0 .

Thanks, Christo

--- End quote ---

OK, I'll investigate. But after I find the reason for a ClassBrowser crash.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version