This content has been marked as final. Show 6 replies
Doing some searching suggests that you might be using the "International Components for Unicode" (http://site.icu-project.org/home) either directly or indirectly with an IBM product.
The particular function where the segmentation fault is occurring looks to be setting the codepage:
A couple of search hits indicate that a #define fsetcodepage u_fsetcodepage_3_8 might be in a header file used on your system.
Thanks! You are dead on. We are using Banner 8 libraries which uses UFT 8 character set and does use ustdio.h. Now I am trying to figure out how to fix this.
Now I am trying to figure out how to fix this.
Hmm, well that will be the fun part. :) If Pro*C was upgraded, the Oracle Client must have been too, perhaps other things as well... Does the segmentation fault always reproduce? Do compiler settings (i.e. optimization) have any impact?
Segmentation fault happens as soon as program is run and happens every time. One thing is I have noticed is that it only happens in programs using curses.h. I am wondering if curses is not compatible with ustdio.
We are having simular problems trying to run programs that use curses.h
Has any solution been found yet?
Thanks for any help.
I came across your problem on the Oracle Discussions Forum from back on June of 2009.
I am working with a pro*c program, in Banner 8. I getting the same message from a core dump,, that you got. I was hoping
you might have written down what you did to resolve it.
My pro*c program is key to running all the SQR code we have. So it's very important. The version of sqr that gets
linked into it is 32-bit and our environment is 64-bit. Our contract with Oracle for SQR has lapsed (it's a long
and expensive story and this is probably not the place). My whole migration to Oracle 11 is being held up by this.
I realize it's been a while since you worked on it but if you could tell me how you resolved your problem, I might be
able to do the same.
North Shore Community College
cell 978 423 6867