User forums > Embedded development
Question on cbSystemView - an SVD plugin
jimbo:
--- Quote from: jimbo on November 26, 2018, 04:53:54 pm ---Keep getting seg faults with this plugin as it stands, running from a recent nightly.
Problem is that now Codeblocks segs faults on startup, and I need to know how to disable this plugin from running , so what does Codeblocks do when you install a plugin? Does it move it to a new location, and have some sort of database files to refenrece? Or similar? Where are these config files so I can manually edit and disble the plugin so I can get codeblocks to restart. Been googling and grepping tmy filesystem looking for stuff, but not found anything.
Note I am using a home build codeblocks, running it from src/src/.lib, which could well be part of the problem.
Running Lubuntu.
--- End quote ---
What I think has happened is that this SVD plugin has somehow broken the debugger toolbar in the system itself, because the calls stack shows a problem in the debugger, rather than in the cbSystemView plugin itself (and after starting ins safe mode, the cbSystem view plugin is not actually installed). Any ideas how I recover this?
--- Code: ---#0 0x00007ffff4fe79cf in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_replace(unsigned long, unsigned long, wchar_t const*, unsigned long) ()
at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00007fffc69152de in DebuggerGDB::GetCurrentPosition(wxString&, int&) () at /usr/local/lib/codeblocks/plugins/libdebugger.so
#2 0x000055555562e3e3 in DebuggerToolbarHandler::OnUpdateUI(wxUpdateUIEvent&) (this=0x5555561b1f90, event=...) at debuggermenu.cpp:822
#3 0x00007ffff56394be in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#4 0x00007ffff56395c3 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5 0x00007ffff563998b in wxEvtHandler::TryHereOnly(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#6 0x00007ffff5639783 in wxEvtHandler::DoTryChain(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#7 0x00007ffff5639a75 in wxEvtHandler::ProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#8 0x00007ffff5f6918b in wxWindowBase::TryAfter(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#9 0x00007ffff5f4f7b0 in wxToolBarBase::UpdateWindowUI(long) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#10 0x00007ffff5f6a713 in wxWindowBase::SendIdleEvents(wxIdleEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#11 0x00007ffff5f6a748 in wxWindowBase::SendIdleEvents(wxIdleEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#12 0x00007ffff5dff60f in wxFrame::SendIdleEvents(wxIdleEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#13 0x00007ffff5e40dbd in wxAppBase::ProcessIdle() () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#14 0x00007ffff5d66bc9 in wxApp::DoIdle() () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#15 0x00007ffff5d66cc3 in () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#16 0x00007ffff402d1f5 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff402d5c0 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff402d8d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff3acea37 in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#20 0x00007ffff5d86b05 in wxGUIEventLoop::DoRun() () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#21 0x00007ffff54f5a93 in wxEventLoopBase::Run() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#22 0x00007ffff54bd0a6 in wxAppConsoleBase::MainLoop() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#23 0x000055555560600e in CodeBlocksApp::OnRun() (this=0x555555a5a4a0) at app.cpp:870
#24 0x00007ffff5547ae9 in wxEntry(int&, wchar_t**) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#25 0x000055555560341f in main(int, char**) (argc=1, argv=0x7fffffffdf58) at app.cpp:338
--- End code ---
oBFusCATed:
What do you mean by recover?
jimbo:
By recover I mean get it back to a state where codeblocks will start up again.
In fact, I got to the state by sudo make install
WHich actually showed up what I was doing wrong - becaue i was running codeblock from ./src/sr/.lib for some reason when I sinstalled the plugin it was not getting copied to the /usr/local/libs/codeblocks/plugins folder, which meant that some resources were not being loaded correctly from the zip ile as it coudlnt find. it.
The plugin still isn't starting up for some reason, but at least the crashing has stopped for the moment as I am now running the codeblocks that is installed by sudo make install. I feel sure there is a better way of doing dev work on plugins and codeblocks at the same time...
Just getting this on the command line.
--- Code: ---Initializing plugins...
KeyBinder failed UpdateById on[2384][cbSystemView...]
KeyBinder failed UpdateById on[923][Window]
Loading menubar...
Editor Tweaks plugin: Building menu
Editor Tweaks plugin: making the menu 15
Editor Tweaks plugin: Folding menu
Loading menubar...
Editor Tweaks plugin: Building menu
Editor Tweaks plugin: making the menu 15
Editor Tweaks plugin: Folding menu
Failed
Failed
--- End code ---
oBFusCATed:
Something is wrong with your install. Probably C::B is loading plugins from two places and in both of them you have the same plugins.
If you've not passed a non-default prefix to configure it is a good idea to do so. It will make it a lot easier to clean up your install and start over.
BlueHazzard:
--- Quote ---Edit: patches 0004 to 0010 applied OK, 0011 won't apply, so just sorting that out.
--- End quote ---
That should be ok, because the last patch is only for setting values, so as long you do not set a value in the svd plugin everything should work
--- Quote ---From my POV, for an interim solution, a button on the plugin to refresh the GUI would be fine until whatever new 'event' system is in place, so would this be a feasible approach? It requires the memory range changes, which just need to be code reviewed, plus a minor change to the plugin to add abutton for refresh instead of having it happen automatically?
--- End quote ---
I do not think that a button is a bad idea... Just add a poll timer that updates the memory watches every 1 sek or so and check for the modified flag in the watch.
--- Quote ---Keep getting seg faults with this plugin as it stands, running from a recent nightly.
--- End quote ---
Ofc this would not work with the current nightly. Why not try my branch on github?
--- Quote ---What I think has happened is that this SVD plugin has somehow broken the debugger toolbar in the system itself,
--- End quote ---
nope, i does not modify the toolbar...
One try to find what is going wrong you can start codeblocks trough gdb
--- Code: ---gdb codeblocks
--- End code ---
--- Quote ---By recover I mean get it back to a state where codeblocks will start up again.
--- End quote ---
As obfuscated said, search for the .so file of the plugin and delete it...
--- Quote ---If you've not passed a non-default prefix to configure it is a good idea to do so. It will make it a lot easier to clean up your install and start over.
--- End quote ---
This is so important... why do we not use the /opt/ directory as default target? This would help a lot beginners to clean up everything...
Also you would not have this problem if you build codeblocks with codeblocks ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version