lfranz Posted December 10, 2012 Report Posted December 10, 2012 Hello fellows, I'm working on a big design and i am facing a "segmentation fault" problem. I debug it a lot but i am in doubt in how much big can be a port vector. For exemplo, an sc_in<double> input[1024] is too big to systemc handle it? Someone knows if the systemc has a limitation on the size of ports array? any information can be helpfull. Quote
apfitch Posted December 10, 2012 Report Posted December 10, 2012 I don't think there's a limitation. However you might be running into some stack limit in your compiler. Try creating a dynamically allocated array, e.g. sc_in<double> * input; then allocate the memory using new in the constructor. regards Alan P.S. Or perhaps sc_vector would help in SystemC 2.3.0? maehne 1 Quote
dakupoto Posted December 11, 2012 Report Posted December 11, 2012 Hello, Segmentation faults are caused mostly when one attempts to dereference a NULL pointer. So, if ports array that you use is to be created dynamically, you have to ensure that it is actually created, before trying to add any element to it, especially when as you mention, it is a complicated/large design. Hope that helps. Quote
lfranz Posted December 11, 2012 Author Report Posted December 11, 2012 Thank you for the reply!! I will try to make it dynamically. If i have success i will comment. Regards. Quote
lfranz Posted December 11, 2012 Author Report Posted December 11, 2012 Hello, I was investigating the problem and it seems that the stack of my linux is limited to 10240 (ulimit -s). I don't ahve to much experience with the memory allocation but my question is: it is a better approach to modify the stack or to make dynamic allocation on my systemc program? the problem is tht if i have to modify the systemc the hand work will be very big. Thank you for the help!!! Quote
apfitch Posted December 11, 2012 Report Posted December 11, 2012 I guess you've answered your own question :-) , as it sounds like you feel the work to modify your code is too much. However if you can afford the time, then using dynamically allocated memory is better. Suppose you want to run the code on another operating system in the future? Or give the code to someone else to run? Then using dynamic memory allocation makes it more likely your code will work on other OS, or for someone else. Often in electronics (and life!) there is the "80/20" rule where most of the problem lies in the 20% area - perhaps you can reduce the problem by attacking just the "20%" and leaving other code untouched? Good luck! Alan Quote
dakupoto Posted December 12, 2012 Report Posted December 12, 2012 Respected Sir, In my humble opinion, how is dynamic memory allocation related to (a) operating system or ( different user using a piece of code Using static allocation forces the programmer to analyze the problem to be solved, in a disciplined manner, removing the irritating issue of tracking down segmentation faults/ memory leaks -- when a 'new' is not followed by a matching 'delete' -- especially in a large complicated design with lots of interacting modules. Also, if someone provides a large piece of code, and I do try to understand the guts of it, then I am headed for trouble. Quote
maehne Posted December 12, 2012 Report Posted December 12, 2012 I agree with Alain, You should opt for dynamic allocation of your memory -- in this case for your array of ports. By using a container such as sc_vector from SystemC 2.3 or boost::ptr_vector from Boost, the deallocation of the dynamic memory will be automatically handled upon the destruction of the surrounding module or, in general, when the current context is exited. The dynamic allocation of the ports has the additional advantage that you can explicitly call each individual constructor with the necessary arguments to achieve the correct naming of the ports in your design hierarchy. If these containers do not fit your needs using the smart pointers (e.g., shared_ptr<T> , weak_ptr<T> , unique_ptr<T> ) provided by C++ 11, C++ TR1 or Boost may be an alternative. They make handling of dynamic memory much safer, as they also handle the automatic deletion upon context exit or when no one is anymore referencing memory. Best regards, Torsten Maehne Quote
lfranz Posted December 12, 2012 Author Report Posted December 12, 2012 Thank for the reply!!! I will extend the limit of my stack memory for now as a fast solution. In the future release of the code i will use some dynamic allocation. Once again thank you for the tips!! Quote
apfitch Posted December 12, 2012 Report Posted December 12, 2012 Hi Dakupoto, in my experience, gcc on Linux generally has much more stack "out of the box" than Visual C++ - I think Visual C++ defaults to about 1MByte of stack. Regarding different users - see the comment above about ulimit... environment changes for each user can affect the amount of stack as well. If you use dynamic memory, it shouldn't matter how much stack the compiler allocates by default, or how much the user environment/sysadmin gives each user/process, regards Alan Quote
david.wcc Posted January 2, 2013 Report Posted January 2, 2013 Hi : I would like to provide my experience of programming on both Qt and Visual C++ platforms. Yes, there is a limitation for the compiler specially when you program with a thread(process). It will shunt down if you generate a large file up to around 500M byte with a thread under Qt platform . Although I modified codes by using the dynamic allocation, it still shunt down. Finally, i just re-wrote it under console mode(DOS mode). Recently, i try the new version of visual C++, it can generate a file up to 7G bytes with a thread. By the way, Bjarne Stroustrup(creator of C++) has an idea for a simple GC as bellow : // ConsoleApplication1.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <iostream> #include <map> #include <vector> using namespace std; class Register { map<void*,void (*)(void*)> m; public : void insert(void* po, void (*pf)(void*)) { m[po]=pf;} void remove(void* po){m.erase(po);} void showInf(){cout<<"There are "<<m.size()<<" shape elements "<<endl;} }; Register cleanup_register; class shape { protected : int x,y; static void cleanup(void* pv) { shape* px = (shape*)pv; cleanup_register.remove(px); // delete px; } public: shape(int vx, int vy) { x=vx; y=vy; cout<<" shape constructor "<<endl; cleanup_register.insert(this,&cleanup); } ~shape(){ cleanup(this); } virtual void draw()=0; }; class circle : public shape{ int z; public: circle(int vx, int vy, int vz):shape(vx,vy){ z =vz ; cout<<" circle constructor "<<endl;} void draw(){ cout <<" is a circle at "<<x<<" : "<<y<<" : "<<z<<endl;} }; class line : protected shape{ int z; public: line(int vx, int vy):shape(vx,vy){ cout<<" circle constructor "<<endl;} void draw(){ cout <<" is a circle at "<<x<<" : "<<y<<endl;} }; int _tmain(int argc, _TCHAR* argv[]) { vector<shape*> shapeVector0; vector<shape*> shapeVector1; vector<shape*> shapeVector2; shapeVector0.push_back(new circle(4,7,5)); shapeVector0.push_back(new circle(4,7,5)); shapeVector0.push_back(new circle(2,5,7)); shapeVector1.push_back(new circle(6,8,3)); shapeVector1.push_back(new circle(4,7,5)); shapeVector1.push_back(new circle(1,4,6)); shapeVector2.push_back(new circle(2,4,7)); shapeVector2.push_back(new circle(5,7,6)); shapeVector2.push_back(new circle(1,5,7)); cleanup_register.showInf(); system("Pause"); return 0; } The result will be ............. shape constructor circle constructor shape constructor circle constructor shape constructor circle constructor shape constructor circle constructor shape constructor circle constructor shape constructor circle constructor shape constructor circle constructor shape constructor circle constructor shape constructor circle constructor There are 9 shape elements Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.