RE: segmentation fault with c4gl
Posted in 2008
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL
Hi Mr. Leffler, Thanks for your reply. The old(working) code was compiled on the same platform. It was compiled with same C compiler and version, same I4GL version. Initially, I ran the command c4gl a.4gl -o a.4ge and there was only one error when I execute the a.4ge stating "Segmentation fault". Now, I did compile it with -a option as you specified through the command c4gl -a a.4gl -o a.4ge and when I execute the a.4ge I get a different error message as "Forms statement error number -1326 An array variable has been referenced outside of its specified dimensions" I will be working on this error. You had asked me to get the stack back-trace using gdb. Since, I am not sure how to do it, I would sincerely request you to throw some light on this point, so that I would be able to know what stack backtracing is, and how core dump file can be generated and recognize them. Finally, I had set the INFORMIXC environment variable to "gcc -g". But, the error message was the same as I above-specified one after executing the 4ge. Regards Kiran. _________________________________________________________________ From salsa lessons to filmy gossip, news to music concerts - watch it all on MSN Video http://video.msn.com/?mkt=en-in
On Thu, Aug 7, 2008 at 3:09 AM, Kiran Kumar <kirang001@hotmail.com> wrote: > The old(working) code was compiled on the same platform. It was compiled with > same C compiler and version, same I4GL version. > > Initially, I ran the command c4gl a.4gl -o a.4ge and there was only one error > when I execute the a.4ge stating "Segmentation fault". Now, I did compile it > with -a option as you specified through the command c4gl -a a.4gl -o a.4ge and > when I execute the a.4ge I get a different error message as > "Forms statement error number -1326 > An array variable has been referenced outside of its specified dimensions" Then your core dump is almost certainly because of this - and tracking this problem down should resolve (at least the first part of) your problem. Most people don't have all that many arrays to deal with, so tracking it down probably won't be too hard - though I'd have to say that doesn't look as helpful as I'd like. Do you have I4GL-RDS? Or, even better, I4GL-ID? If so, use them; they will probably give you a better diagnosis of where the trouble is. > I will be working on this error. > > You had asked me to get the stack back-trace using gdb. Since, I am not sure > how to do it, I would sincerely request you to throw some light on this point, > so that I would be able to know what stack backtracing is, and how core dump > file can be generated and recognize them. As I believe I indicated, when you have a core dump, you can run GDB using the command line: gdb program.4ge core It should give you a prompt - at which you would type 'where' followed by 'quit'. The output from where would be the stack back-trace (unless the stack is so severely trampled that it is useless). However, since you have a clear case of array out of bounds, the stack back trace is of much less interest now. > Finally, I had set the INFORMIXC environment variable to "gcc -g". But, the > error message was the same as I above-specified one after executing the 4ge. With -a in place, the I4GL run-time generates the error and prevents the crash. However, the '-g' option provides debugging output from the C compiler (for use by GDB), but if you try to pass '-g' via the regular command line, it gets eaten by the ESQL/C compiler and not relayed to the C compiler. Hence the subterfuge with the environment variable. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/ "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." NB: Please do not use this email for correspondence. I don't necessarily read it every week, even.
Related threads
- dbexport is not working on database
- Analysis of activities during checkpoint.
- IDS 10 on RHEL4 Linux: I/O benchmark of RAW DEVICES vs BLOCK DEVICES vs COOKED FILES