Problem with C-ISAM support
Posted in 2000
Topics: Platform-Specific Issues, Third-Party Tools & Monitoring, Jobs, Consulting & Announcements
I have had a problem over the past several months getting a bug with the C-ISAM Product (isn't this the basis from which ALL of the Informix Line is developed????) fixed. I am baffled. The problem exists for the C-ISAM software which references the stfloat command. Initially the 'work around' was to change the isam.h header from void stfloat(double source, char *destination); to void stfloat(float source, char *destination); All things being equal, performed the update, and was able to compile the software. That's not the problem however. The REAL problem is that when you attempt to run the actual code which was compiled differently, I get a SIGSEGV. In fact, my Technical Support Contact ALSO GETS a SIGSEGV, even on the premiere platform for Informix, Solaris. My problem was on Linux. My frustration is that the R&D does not want to fix the problem, they want to ignore the problem. But we paid good money for the Product, and for maintenance. So, not that it's been several months, what would you do next? C-ISAM is allegedly the baseline product for the entire Informix product line, I cannot understand why they do not want to fix the software, especially since the problem is well documented, and is verified on multiple platforms. I am frustrated. As a contributor to the Informix FAQ, I used to think that Informix was the better database solution. Guess what I think now. Can you help? Albert E. Whale aewhale@hky.com http://www.hky.com/aewhale.html ------------------------------------------------------------------ ABS Computer Technology, Inc. - Computer & Networking Specialists Sr. Network, Internet and Unix Systems Consultant PAPI - Pennsylvania Parenthood Initiative - Children need BOTH Parents http://www.geocities.com/Heartland/4688/papi.htm Father's Rights Network - http://www.hky.com/frn/frnhome.html
"Albert E. Whale" wrote: > I have had a problem over the past several months getting a bug with the > C-ISAM Product (isn't this the basis from which ALL of the Informix Line > is developed????) fixed. As Mark Stock pointed out, of the Informix DBMS products, only SE uses C-ISAM. Of course, C-ISAM is still useful in its own right; I know of companies who've been very grateful for the recent 7.25 release which removed the 2 GB file size limitation, for example. And C-ISAM is supported, and should work. Even on Linux. > I am baffled. > > The problem exists for the C-ISAM software which references the stfloat > command. > > Initially the 'work around' was to change the isam.h header from > > void stfloat(double source, char *destination); > to > void stfloat(float source, char *destination); Why did you think you needed to change this? That was a bad move. The stfloat() function is written as a function without prototypes -- K&R style -- so you must use the double because the code expects to get a double. If you don't know enough about C and prototypes to understand why this is so, please accept it as a necessity. The explanation would take longer than I'm prepared to commit to at this stage. > All things being equal, performed the update, and was able to compile > the software. That's not the problem however. > > The REAL problem is that when you attempt to run the actual code which > was compiled differently, I get a SIGSEGV. In fact, my Technical > Support Contact ALSO GETS a SIGSEGV, even on the premiere platform for > Informix, Solaris. My problem was on Linux. If you hacked the prototype for stfloat, you are destined for core dumps on any platform. You are telling the code to pass a 4-byte float and a 4-byte pointer to the function, but the function is expecting an 8-byte douhble and a 4-byte pointer (general case, 32-bit platform -- 64-bit considerations ignored). That means the stfloat function is definitely trying to access data that wasn't passed to it; it might even be trying to scribble on the return address for the function call. Whatever it is doing, (if you are using the hacked prototype) it is currently your fault. If you use the correct prototype, the one with the double in it, and you still get a core dump, then you have a bug. > My frustration is that the R&D does not want to fix the problem, they > want to ignore the problem. But we paid good money for the Product, and > for maintenance. What is your case number? What is the bug number? > So, not that it's been several months, what would you do next? Well, in your circumstances, I might send a question to c.d.i. It would be helpful if you can send the minimal test case that reproduces your problem. I guess it should be something along the lines of: #include <isam.h> #include <stdio.h> int main(void) { float f = 3.14159; char buffer[4]; stfloat(f, buffer); puts("OK"); return(0); } I will point out that this code actually works fine for me on Solaris 7 using C-ISAM 7.24.UC1 and GCC 2.95.2. So, the question is 'What are you doing different from me?' When I replace the first line with: /*#include <isam.h>*/ extern void stfloat(float f, char *buffer); the code compiles and produces the OK message and *then* core dumps. This is almost certainly because the return address from main() got trampled by the erroneous call to stfloat() -- which only occurred because I told the C compiler untruths about what the stfloat() function expects as arguments. > C-ISAM is allegedly the baseline product for the entire Informix product > line, I cannot understand why they do not want to fix the software, > especially since the problem is well documented, and is verified on > multiple platforms. If you've hacked the prototype, the problem's of your own making. If you have not hacked the prototype, then you need to explain and illustrate the problem. > I am frustrated. As a contributor to the Informix FAQ, I used to think > that Informix was the better database solution. Guess what I think now. > > Can you help? > > Albert E. Whale aewhale@hky.com > http://www.hky.com/aewhale.html > ------------------------------------------------------------------ > ABS Computer Technology, Inc. - Computer & Networking Specialists > Sr. Network, Internet and Unix Systems Consultant > > PAPI - Pennsylvania Parenthood Initiative - Children need BOTH Parents > http://www.geocities.com/Heartland/4688/papi.htm > Father's Rights Network - http://www.hky.com/frn/frnhome.html -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"
Jonathan Leffler wrote: > > As Mark Stock pointed out, of the Informix DBMS products, only SE uses > C-ISAM. Of course, C-ISAM is still useful in its own right; I know of > companies who've been very grateful for the recent 7.25 release which > removed the 2 GB file size limitation, for example. What do you mean "grateful". The customer just gives you an amount of money to fix something and when they get the fix they've "bought" something, which is nothing to be grateful about for the customer, but rather for the seller to be grateful about. -- David Stes Molenstraat 5 B-2018 Antwerpen, Vlaanderen, Belgie Tel +32 3 237 43 54 Fax +32 3 237 40 76 Email stes@pandora.be
David Stes wrote in message <398886A2.344C1FB2@pandora.be>... >Jonathan Leffler wrote: >> >> As Mark Stock pointed out, of the Informix DBMS products, only SE uses >> C-ISAM. Of course, C-ISAM is still useful in its own right; I know of >> companies who've been very grateful for the recent 7.25 release which >> removed the 2 GB file size limitation, for example. > >What do you mean "grateful". The customer just gives you an amount of >money to fix something and when they get the fix they've "bought" >something, which is nothing to be grateful about for the customer, but >rather for the seller to be grateful about. > ??? This is not a fix but an enhancement to the product. I sell you a bike and the sell you panniers for it. Are you grateful I sold you the panniers or do you expect them because I sold you the bike??? >-- >David Stes Molenstraat 5 B-2018 Antwerpen, Vlaanderen, Belgie >Tel +32 3 237 43 54 Fax +32 3 237 40 76 Email stes@pandora.be