Help : Segmentation fault (core dumped)
Posted in 1999
After migrating to IDS 7.30.FC7 with I4GL 7.20.UE1 on Compaq/DEC Alpha, previously working 4GL programs died with "Segmentation fault (core dumped)" around a PREPARE/DECLARE cursor/FOREACH block; adding DISPLAY and SLEEP statements made it run. Early replies blamed a known 4GL bug where PREPARE inserts extra spaces and overflows the query string buffer (workaround: enlarge the char array). The actual fix, from Naresh, was the DEC C compiler default K&R mode (-std0): recompiling with -std (or -std1), via the c4gl command line or the c4gl script's INFORMIXC call, cured it. The poster confirmed it worked.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Stored Procedures & SPL, Connectivity: ESQL/C, 4GL & Embedded SQL, Versions, Editions & End-of-Life
Hi, We have some problems since we migrated to IDS 7.30.FC7, i4gl 7.20.UE1, platform Compaq Alpha (formerly DEC). Programs which were fine don't work anymore and produce the message "Segmentation fault (core dumped)" without any other kind of information. Hereby the part of the program that used to work fine and doesn't work any more : ... prepare stat_ctrl from query_part declare cu_ctrl cursor with hold for stat_ctrl let keep_error = 100 foreach cu_ctrl into ctrl.* .... end foreach .... and the same with some displays statements which work the problem out : .... display query_part sleep 1 display "before prepare" #sleep 1 prepare stat_ctrl from query_part display "before declare" #sleep 1 declare cu_ctrl cursor with hold for stat_ctrl let keep_error = 100 display "before foreach" sleep 1 foreach cu_ctrl into ctrl.* ... end foreach ... If I take out any of the remaining messages, it doesn't work anymore. The same thing for the remaining "sleep" statements. Has anyone of you any idea about it ? Any help would be greatly appreciated. Thanks in advance. Olmedo Monteverde PNI Informatique Lausanne, Switzerland o.monteverde@naville-livre.ch
Olmedo Monteverde wrote: > Hi, > > We have some problems since we migrated to IDS 7.30.FC7, > i4gl 7.20.UE1, platform Compaq Alpha (formerly DEC). > > Programs which were fine don't work anymore and produce > the message "Segmentation fault (core dumped)" without > any other kind of information. > > Hereby the part of the program that used to work fine and > doesn't work any more : > > ... Core dumps are often due to memory over-writes and leaks, I understand from some previous complaints by users, some versions of Informix 4GL add extra spaces when preparing a statement, hence may cause a memory over-write, and corrupt some other information your program expected at that memory location. From your example I am almost sure that you are the unfortunate victim of such a release version. Solution 1). Upgrade to a newer version of i4gl. Solution 2). Contact me for a Free copy of QueriX 4GL compiler. I will be glad to help. More details about QueriX @ http://www.querix.com/ > > > prepare stat_ctrl from query_part > declare cu_ctrl cursor with hold for stat_ctrl > let keep_error = 100 > foreach cu_ctrl into ctrl.* > > .... > end foreach > .... > > and the same with some displays statements which > work the problem out : > > .... > > display query_part > sleep 1 > display "before prepare" > #sleep 1 > prepare stat_ctrl from query_part > display "before declare" > #sleep 1 > declare cu_ctrl cursor with hold for stat_ctrl > let keep_error = 100 > display "before foreach" > sleep 1 > foreach cu_ctrl into ctrl.* > ... > end foreach > > ... > > If I take out any of the remaining messages, it doesn't work > anymore. The same thing for the remaining "sleep" statements. > > Has anyone of you any idea about it ? Any help would be > greatly appreciated. > > Thanks in advance. > > Olmedo Monteverde > PNI Informatique > Lausanne, Switzerland > o.monteverde@naville-livre.ch
Make sure that the string query_part is MORE THAN large enough to hold the query string. There seems to be a bug in 4GL 7.30 whereby PREPARE rewrites the SQL string with some imbedded spaces which may cause the string to overflow the bounds of the char array causing weird behavior or core dumps like you are seeing. Try printing out the contents of query_part immediately before and after the PREPARE and see what it's contents are. If the string has changed then you are running into that bug. A patch is apparently in the works, the workaround is to make the char array query_part much larger so it will not overflow. Art S. Kagel Olmedo Monteverde wrote: > > Hi, > > We have some problems since we migrated to IDS 7.30.FC7, > i4gl 7.20.UE1, platform Compaq Alpha (formerly DEC). > > Programs which were fine don't work anymore and produce > the message "Segmentation fault (core dumped)" without > any other kind of information. > > Hereby the part of the program that used to work fine and > doesn't work any more : > > ... > > prepare stat_ctrl from query_part > declare cu_ctrl cursor with hold for stat_ctrl > let keep_error = 100 > foreach cu_ctrl into ctrl.* > > .... > end foreach > .... > > and the same with some displays statements which > work the problem out : > > .... > > display query_part > sleep 1 > display "before prepare" > #sleep 1 > prepare stat_ctrl from query_part > display "before declare" > #sleep 1 > declare cu_ctrl cursor with hold for stat_ctrl > let keep_error = 100 > display "before foreach" > sleep 1 > foreach cu_ctrl into ctrl.* > ... > end foreach > > ... > > If I take out any of the remaining messages, it doesn't work > anymore. The same thing for the remaining "sleep" statements. > > Has anyone of you any idea about it ? Any help would be > greatly appreciated. > > Thanks in advance. > > Olmedo Monteverde > PNI Informatique > Lausanne, Switzerland > o.monteverde@naville-livre.ch
Since I beat Mehdi up yesterday, let me say that this is a GREAT post. Bravo. To Mehdi: Yes, that is what we need to see. You answered the question suggested a mainline solution (though a fixed version is not yet available) and then suggested trying Querix as an option. Well done, this is being a responsible net denizen and not a spammer. Welcome. Mehdi wrote: > > Olmedo Monteverde wrote: [Question SNIPPED] > Core dumps are often due to memory over-writes and leaks, I understand > from some previous complaints by users, some versions of Informix 4GL > add extra spaces when preparing a statement, hence may cause a memory > over-write, and corrupt some other information your program expected at > that memory location. From your example I am almost sure that you are > the unfortunate victim of such a release version. > > Solution 1). Upgrade to a newer version of i4gl. > > Solution 2). Contact me for a Free copy of QueriX 4GL compiler. I will > be glad to help. More details about QueriX @ http://www.querix.com/ [SNIP] Art S. Kagel
As I said before we welcome positive criticism and act accordingly to improve ourselves, services and products. "Art S. Kagel" wrote: > Since I beat Mehdi up yesterday, let me say that this is a GREAT post. > Bravo. > > To Mehdi: > Yes, that is what we need to see. You answered the question suggested a > mainline solution (though a fixed version is not yet available) and then > suggested trying Querix as an option. Well done, this is being a > responsible net denizen and not a spammer. Welcome. > > Mehdi wrote: > > > > Olmedo Monteverde wrote: > [Question SNIPPED] > > Core dumps are often due to memory over-writes and leaks, I understand > > from some previous complaints by users, some versions of Informix 4GL > > add extra spaces when preparing a statement, hence may cause a memory > > over-write, and corrupt some other information your program expected at > > that memory location. From your example I am almost sure that you are > > the unfortunate victim of such a release version. > > > > Solution 1). Upgrade to a newer version of i4gl. > > > > Solution 2). Contact me for a Free copy of QueriX 4GL compiler. I will > > be glad to help. More details about QueriX @ http://www.querix.com/ > [SNIP] > > Art S. Kagel
Hi, Mehdi wrote : > From your example I am almost sure that you are > the unfortunate victim of such a release version. I do not think so, as the problem of adding extra spaces in PREPARE has come in 7.30.UC1 & the same is yet to be released for DEC (Compaq Alpha). Olmedo, is there any migration at the OS level, particularly to OS 4.0D from some previous version ? If yes, then please try the foll : ----------------- During run-time, a core dump occurs while running a executable obtained from .ec file which has some cursor statements. DEC compilers have 3 options for C conventions, i) -std0 K & R C [ DEFALULT ] ii) -std ANSI C with Extensions iii) -std1 ANSI C The core dumps occur at the _iqcddcl call only when the compilation is with -std0 option & works fine otherwise. The same .ec file was tested with 7.24.FC5 server esql product & it behaved exactly the same. As the source code for esql layer of 7.20.UD2 Tools is taken from the 7.24.FC5 server source line, this behaviour is understandable. Thus, it can be concluded that the problem is NOT associated with 7.20.UD2 Tools. Instead suspicions seem to revolve around the DEC C compiler (Rev. 878), rather than the server esql product. All the 3 standards worked fine when tested with OS 4.0B. ---------------- The product versions may not be the same, but nature of problem seems similar. What you need to try is, change the script $INFORMIXDIR/bin/c4gl, at the point when it call the system C compiler(INFORMIXC variable). There add the -std or -std1 option & try running the program after recompiling. Alternatively, you may give the -std/std1 option at c4gl command line. Regards, Naresh Olmedo Monteverde wrote: > > Hi, > > We have some problems since we migrated to IDS 7.30.FC7, > i4gl 7.20.UE1, platform Compaq Alpha (formerly DEC). > > Programs which were fine don't work anymore and produce > the message "Segmentation fault (core dumped)" without > any other kind of information. > > Hereby the part of the program that used to work fine and > doesn't work any more : > > ... > > prepare stat_ctrl from query_part > declare cu_ctrl cursor with hold for stat_ctrl > let keep_error = 100 > foreach cu_ctrl into ctrl.* > > .... > end foreach > .... > > and the same with some displays statements which > work the problem out : > > .... > > display query_part > sleep 1 > display "before prepare" > #sleep 1 > prepare stat_ctrl from query_part > display "before declare" > #sleep 1 > declare cu_ctrl cursor with hold for stat_ctrl > let keep_error = 100 > display "before foreach" > sleep 1 > foreach cu_ctrl into ctrl.* > ... > end foreach > > ... > > If I take out any of the remaining messages, it doesn't work > anymore. The same thing for the remaining "sleep" statements. > > Has anyone of you any idea about it ? Any help would be > greatly appreciated. > > Thanks in advance. > > Olmedo Monteverde > PNI Informatique > Lausanne, Switzerland > o.monteverde@naville-livre.ch
Thank you to all of you for the time you spent reading -and finding a solution to- through my problem. Naresh was right. Adding up the option "-std" to the c4gl instruction cleared up the trouble. Once again, thank you very much. Olmedo. Olmedo Monteverde a 'crit dans le message <7vpjqp$dm9$1@pollux.ip-plus.net>... >Hi, > >We have some problems since we migrated to IDS 7.30.FC7, >i4gl 7.20.UE1, platform Compaq Alpha (formerly DEC). > >Programs which were fine don't work anymore and produce >the message "Segmentation fault (core dumped)" without >any other kind of information. > >Hereby the part of the program that used to work fine and >doesn't work any more : > >... > >prepare stat_ctrl from query_part >declare cu_ctrl cursor with hold for stat_ctrl >let keep_error = 100 >foreach cu_ctrl into ctrl.* > > .... >end foreach >.... > > >and the same with some displays statements which >work the problem out : > > >.... > >display query_part >sleep 1 >display "before prepare" >#sleep 1 >prepare stat_ctrl from query_part >display "before declare" >#sleep 1 >declare cu_ctrl cursor with hold for stat_ctrl >let keep_error = 100 >display "before foreach" >sleep 1 >foreach cu_ctrl into ctrl.* > ... >end foreach > >... > >If I take out any of the remaining messages, it doesn't work >anymore. The same thing for the remaining "sleep" statements. > >Has anyone of you any idea about it ? Any help would be >greatly appreciated. > >Thanks in advance. > >Olmedo Monteverde >PNI Informatique >Lausanne, Switzerland >o.monteverde@naville-livre.ch > > > >