Working with a rather complex model, after much additions to a previously working cell, I finally got it to compile with no errors. Almost. I get a segmentation violation, pointed to the end of a .ses file that is loaded automatically. After mucking around, I traced the problem to activation of CVode. Setting the default to inactive removes the error. However, manually activating it after compile replicates it. I also get a Signal 6 (whatever that means).
I have never had a problem with CVode outside the NMODL field -- and this time all the mod files work 100%.
So the question is, what should I look for in the code? The difference between a working and a broken simulation is mostly in complexity of synaptic activity...I am at a complete loss, and removing things bit by bit (back to the working version) will take years...
Not too familiar with core_dump, but that just makes the NRN exit right away. Any way to display, debug the processes that lead to the error, to zero in on a faulty code?
Thanks for any help!
Another CVode, segmentation violation question
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
In order to diagnose a problem, you must first localize its source.
and refinements one at a time, in small increments, testing at every step. An incremental
cycle of revision and testing is essential when you're working on a complex project.
the problem.
Parse errors produce an immediate error message without executing your simulation.
If the error message isn't informative, comment out lines or blocks of code to try to find
the problem.
Runtime errors can be localized by inserting print statements that report the course of
program execution.
Then go back to the working version--you did save that, right?--and add complicationsremoving things bit by bit (back to the working version) will take years...
and refinements one at a time, in small increments, testing at every step. An incremental
cycle of revision and testing is essential when you're working on a complex project.
Your best tool is between your ears. Use it to trick NEURON into helping you localizeAny way to display, debug the processes that lead to the error, to zero in on a faulty code?
the problem.
Parse errors produce an immediate error message without executing your simulation.
If the error message isn't informative, comment out lines or blocks of code to try to find
the problem.
Runtime errors can be localized by inserting print statements that report the course of
program execution.
In Dutch we have a saying "Als het kalf verdronken is, dempt men de put" meaning in rough translation "After the calf has drowned the well is filled up". So here a suggestion to get rid of the well and overcome your inability to restore your future working versions, install version control.
The website
http://www.third-bit.com/swc/
gives a gentle introduction to version control using Subversion.
See also the hot tip:
https://www.neuron.yale.edu/phpBB2/viewtopic.php?t=198
Combined with a graphical component RapidSVN and a good diff program it will be a great tool to keep your code tidy and it will allow you to leap back to a previous working version at any time.
Here some some instructions I give to students and colleagues whom I try to lure into using version control (on windows):
The website
http://www.third-bit.com/swc/
gives a gentle introduction to version control using Subversion.
See also the hot tip:
https://www.neuron.yale.edu/phpBB2/viewtopic.php?t=198
Combined with a graphical component RapidSVN and a good diff program it will be a great tool to keep your code tidy and it will allow you to leap back to a previous working version at any time.
Here some some instructions I give to students and colleagues whom I try to lure into using version control (on windows):
Code: Select all
For version control with subversion (under windows) please install the following, in the given order from an administrator account:
Apache server and libraries:
http://apache.nedzone.nl/httpd/binaries/win32/apache_2.0.55-win32-x86-no_ssl.msi
Subversion itself, built on Apache libraries:
http://subversion.tigris.org/files/documents/15/29065/svn-1.3.0-setup.exe
Widgets wxwindows:
http://prdownloads.sourceforge.net/wxwindows/wxMSW-2.6.2-Setup.exe
RapidSVN Subversion GUI built on Apache and wxwidgets libraries:
http://rapidsvn.org/download/RapidSVN-0.9.0.exe
Other programs that make life easier are:
A diff program, showing differences between two files (text or word
documents)
http://www.componentsoftware.com/Products/CSDiff/download.htm
A good plain text editor:
http://www.pspad.com/en/download.php
General intro on best programming practices, including INTRODUCTION TO SUBVERSION
http://www.third-bit.com/swc/
Configuration:
To benefit most from version management you have to automate a few things.
RapidSVN offers a nice GUI but adding the right settings will give this tool extra leverage.
In the menu under View->Preferences (Programs Tab) you can add links to programs needed for common tasks.
In my case I have the following settings, please modify to fit your program locations etc.
Standard editor:
D:\ProgramFiles\PSPadEditor\PSPad.exe
Program arguments (%1=selected file)
%1
Standard file explorer:
explorer.exe
Program Arguments (%1=selected directory)
%1
Diff tool:
D:\ProgramFiles\ComponentSoftware\CSDiff\CSDiff.exe
Program Arguments (%1=file1, %2=file2):
%2 %1
PSPad offers syntax highlighting, this can be customized using Settings->Highlighter Settings.
For NEURON syntax highlighting files can be found at:
https://www.neuron.yale.edu/phpBB2/viewtopic.php?t=148
Thank you for your suggestions!
This case is a bit different from normal practices I would follow, due to the nature of the model (for ex., I had to make some rather radical changes, splitting input streams, etc) -- it would've been hard to do that incrementally, it was more of a tear-down-and-rebuld kind of thing. So what I am stuck with is a code that compiles (so no parse errors), but the runtime error is not really runtime since the run() statement never gets a chance to be called -- all it takes for the error to pop up is setting CVode[0].active(1), after compilation.
I have followed previous similar threads looking for a way to diagnose these kind of errors, but have not found any way to track NEURON's instruction executions to find out what made it give a generic segmentation error (again, core_dump does not help -- but something like WinXP's "debug" button would be awesome :) ).
Sorry if this is monotonous -- I suspect it is probably something simple, hiding in pages of code, which is why I would rather first try to debug, rather than incrementally scale back in many different modules at once...
This case is a bit different from normal practices I would follow, due to the nature of the model (for ex., I had to make some rather radical changes, splitting input streams, etc) -- it would've been hard to do that incrementally, it was more of a tear-down-and-rebuld kind of thing. So what I am stuck with is a code that compiles (so no parse errors), but the runtime error is not really runtime since the run() statement never gets a chance to be called -- all it takes for the error to pop up is setting CVode[0].active(1), after compilation.
I have followed previous similar threads looking for a way to diagnose these kind of errors, but have not found any way to track NEURON's instruction executions to find out what made it give a generic segmentation error (again, core_dump does not help -- but something like WinXP's "debug" button would be awesome :) ).
Sorry if this is monotonous -- I suspect it is probably something simple, hiding in pages of code, which is why I would rather first try to debug, rather than incrementally scale back in many different modules at once...
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
. . .MishaZ wrote:runtime error is not really runtime since the run() statement never gets a chance to be called -- all it takes for the error to pop up is setting CVode[0].active(1)
If the code is truly modular, it should be a simple matter to comment out large chunks of itI suspect it is probably something simple, hiding in pages of code, which is why I would rather first try to debug, rather than incrementally scale back in many different modules at once...
and embed print statements at critical points.
Ok, I am starting to feel that I am really missing something here...but I will present my case anyway :) I admit I could've designed the code better suited for scaling back...ted wrote: If the code is truly modular, it should be a simple matter to comment out large chunks of it and embed print statements at critical points.
Taking out chunks of code presents its own problems in that I will have to go over the rest of the code and remove newly dead function, object and segment calls and references -- I do not mean to sound lazy, I just want to make sure it really is the only resort, since it is not an attractive option.
The comment-out method would only work if the code was being executed -- but my concern and difficulty is that the error occurs without execution (since the run() statement is never called -- unless activating CVode somehow executes parts of my code ). And again, everything compiles without errors. NEURON does not print (in this case) the last executed instruction after CVode[0].active(1) is set. What exactly happens in NEURON when CVode is activated, more specifically, how does it interact with the model code, outside of running the actual simulation? And is there any way to track those processes within NEURON itself? I guess this falls back to the debug quesions again...
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Unless you can get somebody else to do it for you, it's the last resort. Hey, it's all yourMishaZ wrote:I just want to make sure it really is the only resort
code, and it's fresh code at that--it's not like somebody gave you a bag full of somebody
else's old code and told you to refactor it.
All top-level statements (statements that appear outside of a proc, func, or template) aremy concern and difficulty is that the error occurs without execution (since the
run() statement is never called
executed, regardless of whether run() has been called. All procs and funcs that are
called by top level statements are likewise executed. Statements inside a template will
also be executed, as appropriate, if an instance of that class is created.
You mean the mod files? Have you checked them with modlunit? Do they use dt?everything compiles without errors
Exactly what happens when a run-time error occurs.NEURON does not print (in this case) the last executed instruction after CVode[0].active(1) is set.