crash when debugging a linux app

[b.timofte]

After i build the application when i try to debug it under linux using advanced cmake i get the error :

The path to the .elf is only 53 chars long on my c: drive ….

 

System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
at System.IO.PathHelper.GetFullPathName()
at System.IO.Path.LegacyNormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
at System.IO.Path.GetFullPathInternal(String path)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at hh1.b(String b, String c, f a)
at k9.h1(bm2 d, yh1 c, wa2 a, Boolean b)
at k9.j.b(ml1 a)
at k22.u`1.d(ml1 a)
at VisualGDB.Add_In.Tool_Windows.WPF.DockedProgressPresenter.RunItemizedOperation(Action`1 operation, String caption, ij2 exceptionHandler, String[] stages)
at k22.p_2[_ResultType](a9`1 d, String a, ij2 c, String[] b)
at k9.s1(bm2[] a, String[] d, String b, d3[] e, Boolean c)
at k9.k2(bm2[] c, String[] e, String a, d3 d, Boolean b)
at we2.s()
at we2.t1(DebugCustomizationSettings a)
at y11.e4()
at x4.x_2()
at VisualGDB.GDBDebugEngine.e1(bv1 b, a2 a)

• This topic was modified 5 years, 8 months ago by support. Reason: formatting

[b.timofte]

Also quick debug doesnt work…

System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\$(ProjectDir)'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.CommonInit()
at System.IO.FileSystemEnumerableIterator1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler1 resultHandler, Boolean checkHost)
at System.IO.Directory.GetFiles(String path)
at hh1.b(String b, String c, f a)
at k9.h1(bm2 d, yh1 c, wa2 a, Boolean b)
at k9.j.b(ml1 a)
at k22.u`1.d(ml1 a)
at VisualGDB.Add_In.Tool_Windows.WPF.DockedProgressPresenter.RunItemizedOperation(Action`1 operation, String caption, ij2 exceptionHandler, String[] stages)
at k22.p_2[_ResultType](a9`1 d, String a, ij2 c, String[] b)
at k9.s1(bm2[] a, String[] d, String b, d3[] e, Boolean c)
at k9.k2(bm2[] c, String[] e, String a, d3 d, Boolean b)
at we2.s()
at we2.t1(DebugCustomizationSettings a)
at y11.e4()
at x4.x_2()
at VisualGDB.GDBDebugEngine.e1(bv1 b, a2 a)

 

• This reply was modified 5 years, 8 months ago by support. Reason: formatting

[support]

Unfortunately as you haven’t shared the VisualGDB build number that is usually shown above the stack trace, it’s impossible for us to decode it and locate the exact cause for it.

Generally, as the trace mentions custom debug steps, please try removing them from the .vgdbsettings file and see if the problem persists. If not, please try narrowing it down to a specific debug step that will likely contain an excessively long path. You can also try using View->Other Windows->VisualGDB Diagnostics Console to get a detailed log of the actions performed by VisualGDB.

The second issue looks like you are using a $(ProjectDir) variable in a context where it is not supported (e.g. Quick Debug). Please try searching your .quickdbg file for $(ProjectDir) and edit it to remove the unsupported variable reference. If you are not sure about the exact reference, please try creating a new quick debug preset from scratch, verify that it works and then compare the working and non-working preset.

[Author]

Posts