|
From: Fred S. <fr...@co...> - 2008-04-22 19:30:32
|
When running Valgrind (3.30) against this app I get bazillions of error reports out of the oracle client (10.2.0.3 instant client). There are several slightly different calling sequences, but MANY MANY of them look exactly like the one below. I've seen some questions on Oracle forums about similar reports from Valgrind and they don't seem to get much helpful info back. Anyone here got any words of wisdom on these? Do they represent real bugs (in Oracle, or in my app) or should they all be suppressed? ==32646== Thread 11: ==32646== Use of uninitialised value of size 4 ==32646== at 0x46A3E88: ztced_einit (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x46A3FAD: ztcedgks (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x46A357F: ztcedi (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x46A4803: ztcebi (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x46A32C5: ztcei (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x46A2FCA: ztceenc (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x4625E81: ztcrbm (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x46262E6: ztcrbh (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x462614C: ztcrbp (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x4625C8D: ztcr2seed (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x4626BC2: ztvokg (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x440C73C: kpu8lgn (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x44069A0: kpuauthxa (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x44064DE: kpuauth (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x4493DF5: OCISessionBegin (in /home/interface/interface/lib/libclntsh.so.10.1) ==32646== by 0x8076C25: HS_oci_start (HS_oci.c:566) <snip> And speaking of suppression, I've built a local suppressions file made up of exactly the info produced by valgrind as the suggested suppression code, but some of them continue to be emitted. Any clues on why that is or how to solve it? Thanks! Fred Smith Senior Applications Programmer/Analyst Computrition, Inc. fr...@co... <mailto:fr...@co...> 781-275-4488x148 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email |
|
From: Julian S. <js...@ac...> - 2008-04-22 19:45:14
|
> When running Valgrind (3.30) against this app I get bazillions of error > reports out of the oracle client (10.2.0.3 instant client). There are > several slightly different calling sequences, but MANY MANY of them look > exactly like the one below. Might be legit, or not; hard to tell. But try this (download and build a development branch of V): svn co svn://svn.valgrind.org/valgrind/branches/OTRACK_BY_INSTRUMENTATION \ otbin cd otbin ./autogen.sh # configure and build as usual Rerun your app using this Valgrind, and see if you still get the errors. If so, rerun but also with the flag --track-origins=yes. This will make it run much more slowly, but might tell you where it believes this uninitialised memory came from. If you still get the errors, it would be useful to post one (of the ones acquired with --track-origins=yes). J |
|
From: Fred S. <fr...@co...> - 2008-04-22 19:47:24
|
Thanks, Julian. I'll give that a try. Fred Smith Senior Applications Programmer/Analyst Computrition, Inc. fr...@co... 781-275-4488x148 > -----Original Message----- > From: Julian Seward [mailto:js...@ac...] > Sent: Tuesday, April 22, 2008 3:40 PM > To: val...@li... > Cc: Fred Smith > Subject: Re: [Valgrind-users] bazillion errors from Oracle Client > > > > When running Valgrind (3.30) against this app I get bazillions of error > > reports out of the oracle client (10.2.0.3 instant client). There are > > several slightly different calling sequences, but MANY MANY of them look > > exactly like the one below. > > Might be legit, or not; hard to tell. But try this (download and > build a development branch of V): > > svn co svn://svn.valgrind.org/valgrind/branches/OTRACK_BY_INSTRUMENTATION > \ > otbin > > cd otbin > ./autogen.sh > > # configure and build as usual > > Rerun your app using this Valgrind, and see if you still get the > errors. > > If so, rerun but also with the flag --track-origins=yes. This > will make it run much more slowly, but might tell you where it > believes this uninitialised memory came from. > > If you still get the errors, it would be useful to post one (of > the ones acquired with --track-origins=yes). > > J This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email |
|
From: Fred S. <fr...@co...> - 2008-04-22 20:51:50
|
Julian:
Thanks for the prompt and informative reply!
I've still got a question (or fifty :) about some of the results:
Here's one of the reports from the new version using the option you
suggested I try:
==11274== Thread 11:
==11274== Use of uninitialised value of size 4 (otag 32152)
==11274== at 0x46A3E88: ztced_einit (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A3FAD: ztcedgks (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A357F: ztcedi (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A4803: ztcebi (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A32C5: ztcei (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A2FCA: ztceenc (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4625E81: ztcrbm (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46262E6: ztcrbh (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x462614C: ztcrbp (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4625C8D: ztcr2seed (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4626BC2: ztvokg (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x440C73C: kpu8lgn (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x44069A0: kpuauthxa (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x44064DE: kpuauth (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4493DF5: OCISessionBegin (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x8076C25: XX_oci_start (XX_oci.c:566)
==11274== by 0x80778D5: XX_do_OCI_stuff (XX_oci.c:1103)
==11274== by 0x804DE44: XX_send2XX (XX_thr_out.c:216)
==11274== by 0x804E1C9: XX_convertandsend (XX_thr_out.c:370)
==11274== by 0x804E537: XX_out_msg (XX_thr_out.c:521)
==11274== by 0x804EC71: XX_out_main (XX_thr_out.c:828)
==11274== by 0x804F08F: XX_main_out (XX_thr_out.c:1041)
==11274== by 0xA463CB: start_thread (in /lib/tls/libpthread-2.3.4.so)
==11274== by 0x8BE1AD: clone (in /lib/tls/libc-2.3.4.so)
==11274== Uninitialised value originates from a stack allocation
==11274== at 0x4625D87: ztcrbm (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274==
What does the "(otag 32152)" at the top tell me?
The uninitialized value originates from within one of the oracle
libraries, apparently in a function named "ztcrbm", and it's a stack
allocation?
Looks like ztcrbm then calls ztceenc, and so on, handing that stack
address downward as it goes. So, I think I can safely assume that it's
not any of MY allocations that are causing this particular report. But I
can't tell if it's a legitimate report, or if it's just an unused
portion of the stack space allocaated there. Correct?
Then there's this one:
==11274== Use of uninitialised value of size 4 (otag 32025)
==11274== at 0x46A40E5: ztcedecb (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A35ED: ztcedencbk (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A4C12: ztceb_encblk (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A49C9: ztcebn (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A3364: ztcen (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46A2FEA: ztceenc (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4625E81: ztcrbm (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x46262E6: ztcrbh (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x462614C: ztcrbp (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4625C8D: ztcr2seed (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4626BC2: ztvokg (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x440C73C: kpu8lgn (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x44069A0: kpuauthxa (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x44064DE: kpuauth (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4493DF5: OCISessionBegin (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x8076C25: XX_oci_start (XX_oci.c:566)
==11274== by 0x80778D5: XX_do_OCI_stuff (XX_oci.c:1103)
==11274== by 0x804DE44: XX_send2XX (XX_thr_out.c:216)
==11274== by 0x804E1C9: XX_convertandsend (XX_thr_out.c:370)
==11274== by 0x804E537: XX_out_msg (XX_thr_out.c:521)
==11274== by 0x804EC71: XX_out_main (XX_thr_out.c:828)
==11274== by 0x804F08F: XX_main_out (XX_thr_out.c:1041)
==11274== by 0xA463CB: start_thread (in /lib/tls/libpthread-2.3.4.so)
==11274== by 0x8BE1AD: clone (in /lib/tls/libc-2.3.4.so)
==11274== Uninitialised value originates from a stack allocation
==11274== at 0x4626567: ztcrsgstk (in
/home/interface/interface/lib/libclntsh.so.10.1)
It says it's due to a stack allocation in ztcrsgstk. But ztcrsgstk does
not appear in the stack trace above. That makes me think that ztcrsgstk
was called, somewhere, and returned the address of some stack space.
I've always thought that was a big NO-NO because once you return the
stack space is no longer yours (or anyone else's) to use. If I'm right,
then this could be a real bug, probably in Oracle's tools. No?
But for some of the issues reported in MY code, I think this may be a
very helpful option. Once I understand it, that is.
Here's one last example from some of my code:
==11274== Conditional jump or move depends on uninitialised value(s)
(otag 36621)
==11274== at 0x479A5DC: ttci2n (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x47AB32D: ttcacs (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x47397AD: ttcdrv (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4621EC4: nioqwa (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x448FD96: upirtrc (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4405A35: kpurcsc (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x43BB9B8: kpuexecv8 (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x43BD409: kpuexec (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x4494901: OCIStmtExecute (in
/home/interface/interface/lib/libclntsh.so.10.1)
==11274== by 0x807709C: XX_check_if_may_connect (XX_oci.c:736)
==11274== by 0x80778FA: XX_do_OCI_stuff (XX_oci.c:1108)
==11274== by 0x804DE44: XX_send2XX (XX_thr_out.c:216)
==11274== by 0x804E1C9: XX_convertandsend (XX_thr_out.c:370)
==11274== by 0x804E537: XX_out_msg (XX_thr_out.c:521)
==11274== by 0x804EC71: XX_out_main (XX_thr_out.c:828)
==11274== by 0x804F08F: XX_main_out (XX_thr_out.c:1041)
==11274== by 0xA463CB: start_thread (in /lib/tls/libpthread-2.3.4.so)
==11274== by 0x8BE1AD: clone (in /lib/tls/libc-2.3.4.so)
==11274== Uninitialised value originates from a stack allocation
==11274== at 0x8076F0C: XX_check_if_may_connect (XX_oci.c:689)
Here's a small snapshot of the code from around line 689:
static XX_IF_STATE XX_check_if_may_connect (XX_out_thread * myoutthr,
XX_IF_PARMS * ifparms)
{ <===============================================
line 689
XX_IF_STATE status = OK;
OCIStmt * stmthp = NULL;
OCIBind * isokbp = NULL;
int isok;
sword OCIrc;
char * OCIsql =
"BEGIN\n"
"SELECT XX_PKGADMIN.MAYUSERCONNECT INTO :isok FROM
DUAL;\n"
"END;\n";
Stmthp and isokbp are initialized by subsequent calls into the OCI
libraries, so it's possible there are uninitialized bits in there
somewhere.
Does valgrind have the information to be any more specific about which
line contains the actual stacked item it's referring to?
Fred Smith
Senior Applications Programmer/Analyst
Computrition, Inc.
fr...@co...
781-275-4488x148
> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...]
> Sent: Tuesday, April 22, 2008 3:40 PM
> To: val...@li...
> Cc: Fred Smith
> Subject: Re: [Valgrind-users] bazillion errors from Oracle Client
>
>
> > When running Valgrind (3.30) against this app I get bazillions of
error
> > reports out of the oracle client (10.2.0.3 instant client). There
are
> > several slightly different calling sequences, but MANY MANY of them
look
> > exactly like the one below.
>
> Might be legit, or not; hard to tell. But try this (download and
> build a development branch of V):
>
> svn co
svn://svn.valgrind.org/valgrind/branches/OTRACK_BY_INSTRUMENTATION
> \
> otbin
>
> cd otbin
> ./autogen.sh
>
> # configure and build as usual
>
> Rerun your app using this Valgrind, and see if you still get the
> errors.
>
> If so, rerun but also with the flag --track-origins=yes. This
> will make it run much more slowly, but might tell you where it
> believes this uninitialised memory came from.
>
> If you still get the errors, it would be useful to post one (of
> the ones acquired with --track-origins=yes).
>
> J
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email
|
|
From: Julian S. <js...@ac...> - 2008-04-22 21:09:14
|
> ==11274== Uninitialised value originates from a stack allocation
> ==11274== at 0x8076F0C: XX_check_if_may_connect (XX_oci.c:689)
>
>
> Here's a small snapshot of the code from around line 689:
>
> static XX_IF_STATE XX_check_if_may_connect (XX_out_thread * myoutthr,
> XX_IF_PARMS * ifparms)
> { <===============================================
> line 689
> XX_IF_STATE status = OK;
> OCIStmt * stmthp = NULL;
> OCIBind * isokbp = NULL;
> int isok;
> sword OCIrc;
> char * OCIsql =
> "BEGIN\n"
> "SELECT XX_PKGADMIN.MAYUSERCONNECT INTO :isok FROM
> DUAL;\n"
> "END;\n";
>
> Stmthp and isokbp are initialized by subsequent calls into the OCI
> libraries, so it's possible there are uninitialized bits in there
> somewhere.
> Does valgrind have the information to be any more specific about which
> line contains the actual stacked item it's referring to?
For boring technical reasons, it only identifies the function in
which the uninitialised data originates. It is possible to do better
but the run time expense increases rapidly.
If you explicitly initialise all the locals in this function
("int isok = 0; sword OCIrc = 0;") does the error go away?
Bear in mind Memcheck's origin tracking code is very new and we
don't have much experience of it yet. I _think_ it's correct,
but ...
J
|
|
From: Fred S. <fr...@co...> - 2008-04-23 13:09:32
|
Pardon the top-post, stupid mail client.
Yes, initializing isok and OCIrc to zero removes that particular
diagnostic.
I guess that is one of those cases I've read about on the list where
some bits aren't initialized but V will diagnose it when the
byte/word/whatever is read from later.
Thanks for the reminder!
Fred Smith
Senior Applications Programmer/Analyst
Computrition, Inc.
fr...@co...
781-275-4488x148
> -----Original Message-----
> From: val...@li...
[mailto:valgrind-users-
> bo...@li...] On Behalf Of Julian Seward
> Sent: Tuesday, April 22, 2008 5:04 PM
> To: val...@li...
> Cc: Fred Smith
> Subject: Re: [Valgrind-users] bazillion errors from Oracle Client
>
>
> > ==11274== Uninitialised value originates from a stack allocation
> > ==11274== at 0x8076F0C: XX_check_if_may_connect (XX_oci.c:689)
> >
> >
> > Here's a small snapshot of the code from around line 689:
> >
> > static XX_IF_STATE XX_check_if_may_connect (XX_out_thread *
myoutthr,
> > XX_IF_PARMS * ifparms)
> > { <===============================================
> > line 689
> > XX_IF_STATE status = OK;
> > OCIStmt * stmthp = NULL;
> > OCIBind * isokbp = NULL;
> > int isok;
> > sword OCIrc;
> > char * OCIsql =
> > "BEGIN\n"
> > "SELECT XX_PKGADMIN.MAYUSERCONNECT INTO :isok FROM
> > DUAL;\n"
> > "END;\n";
> >
> > Stmthp and isokbp are initialized by subsequent calls into the OCI
> > libraries, so it's possible there are uninitialized bits in there
> > somewhere.
> > Does valgrind have the information to be any more specific about
which
> > line contains the actual stacked item it's referring to?
>
> For boring technical reasons, it only identifies the function in
> which the uninitialised data originates. It is possible to do better
> but the run time expense increases rapidly.
>
> If you explicitly initialise all the locals in this function
> ("int isok = 0; sword OCIrc = 0;") does the error go away?
>
> Bear in mind Memcheck's origin tracking code is very new and we
> don't have much experience of it yet. I _think_ it's correct,
> but ...
>
> J
>
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save
$100.
> Use priority code J8TL2D2.
>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
av
> aone
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email
|
|
From: Nicholas N. <nj...@cs...> - 2008-04-22 23:05:43
|
On Tue, 22 Apr 2008, Julian Seward wrote: > For boring technical reasons, it only identifies the function in > which the uninitialised data originates. It is possible to do better > but the run time expense increases rapidly. Just to clarify: that's the case for stack allocated memory. For heap-allocated memory it gives a full stack trace. Fred, your analysis sounds right. Generally knowing where the allocation point of an undefined value is a big help in fixing the problem, but sometimes some detective work is still needed... N |
|
From: Julian S. <js...@ac...> - 2008-04-22 23:13:38
|
On Wednesday 23 April 2008 01:05, Nicholas Nethercote wrote: > On Tue, 22 Apr 2008, Julian Seward wrote: > > For boring technical reasons, it only identifies the function in > > which the uninitialised data originates. It is possible to do better > > but the run time expense increases rapidly. > > Just to clarify: that's the case for stack allocated memory. For > heap-allocated memory it gives a full stack trace. Another comment .. I was slightly nervous about the accuracy of the stack-origins stuff, because (1) it's tricky to get right, especially on x86_64, and (2) during testing a couple weeks back on OOo, it produced an on-stack allocation point which I could not make any sense of. But in other tests the stack allocation points indicated are correct. Fred, is this on x86_64 or just x86 ? J |
|
From: Fred S. <fr...@co...> - 2008-04-23 12:29:53
|
This is X86 (ia32). Centos 4.x on a HP DL320 G2. Fred Smith Senior Applications Programmer/Analyst Computrition, Inc. fr...@co... 781-275-4488x148 > -----Original Message----- > From: val...@li... [mailto:valgrind-users- > bo...@li...] On Behalf Of Julian Seward > Sent: Tuesday, April 22, 2008 7:09 PM > To: val...@li... > Cc: Nicholas Nethercote; Fred Smith > Subject: Re: [Valgrind-users] bazillion errors from Oracle Client > > On Wednesday 23 April 2008 01:05, Nicholas Nethercote wrote: > > On Tue, 22 Apr 2008, Julian Seward wrote: > > > For boring technical reasons, it only identifies the function in > > > which the uninitialised data originates. It is possible to do better > > > but the run time expense increases rapidly. > > > > Just to clarify: that's the case for stack allocated memory. For > > heap-allocated memory it gives a full stack trace. > > Another comment .. > > I was slightly nervous about the accuracy of the stack-origins > stuff, because (1) it's tricky to get right, especially on x86_64, > and (2) during testing a couple weeks back on OOo, it produced an > on-stack allocation point which I could not make any sense of. > But in other tests the stack allocation points indicated are > correct. > > Fred, is this on x86_64 or just x86 ? > > J > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j av > aone > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email |
|
From: Ivan S. J. <isj...@i1...> - 2008-04-23 05:41:28
|
On Tuesday 22 April 2008 21:30:11 Fred Smith wrote: > When running Valgrind (3.30) against this app I get bazillions of error > reports out of the oracle client (10.2.0.3 instant client). The library libclntsh includes some SSL-like encryption. One source of entropy is uninitialized stack data. > Anyone here got any words of wisdom on these? Do they represent real > bugs (in Oracle, or in my app) or should they all be suppressed? I usually suppress everything called from within OCISessionBegin. It is slightly annoying. If you are sure that the authentication credentials (username/password) is initialized correctly in your application, then you can safely suppress OCISessionBegin. /isj |