Hi all,

I'm using SPARC syatems and sun studio8 compiler.I'm getting error as
signal ILL (illegal opcode) in (unknown)
in one of my .cc code.

I tried to put the code in dbx with RTC enabled and got some
messages.But it is very hard to understand those error messages.
I'm pasting the error messages here.Can anyone please explain it what
it exactly means.

(dbx) showleaks
Checking for memory leaks...

Actual leaks report    (actual leaks:         1  total size:      60
bytes)

 Total  Num of  Leaked      Allocation call stack
 Size   Blocks  Block
                Address
======  ====== ==========  =======================================
    60       1    0xab0b0  calloc < nlepeinit < nlstdggo < nlstdgg <
nigini1 < niqname < kwfnran < kwfcinit


Possible leaks report  (possible leaks:       0  total size:       0
bytes)


(dbx) showblock -a 0xab0b0
Block in use (biu):
Found block of size 60 bytes at address 0xab0b0 (Unknown% of total)
At time of allocation, the call stack was:
        [1] calloc() at 0xfe1b7428
        [2] nlepeinit() at 0xfec43050
        [3] nlstdggo() at 0xfec4bab0
        [4] nlstdgg() at 0xfec4b9a0
        [5] nigini1() at 0xfeb6c45c
        [6] niqname() at 0xfeb6d3c0
        [7] kwfnran() at 0xfeac1da4
        [8] kwfcinit() at 0xfea3fcd0

and after getting the error the message displayed as

t@1 (l@1) signal ILL (illegal opcode) in (unknown) at 0xf9552610
0xf9552610:     unimp    0x0
Current function is UnixDB::AllocateDFReturn
   94      void AllocateDFReturn(int iSize) { pDFReturn = new char
[iSize]; };  /* allocate storage for a magnum display
 fmt report */
(dbx) showleaks
Checking for memory leaks...

Actual leaks report    (actual leaks:         0  total size:       0
bytes)



Possible leaks report  (possible leaks:       0  total size:       0
bytes)
(dbx) showmemuse
Checking for memory use...

Blocks in use report   (blocks in use:     1199  total size: 1891660
bytes)

 Total  % of Num of  Avg     Allocation call stack
 Size    All Blocks  Size
======= ==== ====== ======  =======================================
 370494  19%      1 370494  kpummealloc < kpuiniSG < kpummpin < kpupin
< OCIInitialize < sqgctx < sqgrct < sqlcmex
 281764  14%      6  46960  lxldlod < lxdlobj
 266944  14%      2 133472  calloc < nsgbliuc
 192456  10%     34   5660  kpummapg < kghgex
  98316   5%      3  32772  operator new <
std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::basic_filebuf
#Nvaria
nt 1
  66728   3%      2  33364  calloc < nsgbliuc
  66728   3%      2  33364  calloc < nsgbliuc
  66728   3%      2  33364  calloc < nsgbliuc
  66728   3%      2  33364  calloc < nsgbliuc
  36960   1%      6   6160  sqlalc < sqldrl
  36960   1%      6   6160  sqlalc < sqlbrl
  35560   1%      2  17780  calloc < nsgbliuc
  32048   1%      6   5341  sqlalc < sqlbrl
  27136   1%      6   4522  sqlalc < sqldrl
  24579   1%      3   8193  operator new <
std::basic_filebuf<char,std::char_traits<char> >::basic_filebuf
#Nvariant 1
  20340   1%      1  20340  lxldlbb < lxlinit < kpummpin < kpupin <
OCIInitialize < sqgctx < sqgrct < sqlcmex
  18432  <1%      9   2048  nlhtnsl < nlhthnew
  17856  <1%      1  17856  kpummealloc < kpuinit0 < kpuinit <
OCIEnvInit < sqgctx < sqgrct < sqlcmex < sqlcxt
  17120  <1%      1  17120  sqlrlc < sqlcopydfn < sqlrdf < sqlatm <
sqlnst < sqlcmex < sqlcxt < ProcessSQLRequestSelectA
ppg2
  16000  <1%      1  16000  operator new < UnixDB::UnixDB < main

Can u pls expalin what this message exactly means.

Thanks in Advance

Regards.

Hi Paul,

I have put where and checked in dbx.I forgot to paste that.

(dbx) where
current thread: t@1
  [1] 0xf9552610(0xfe5694d0, 0x0, 0xfe56a084, 0x1083287b, 0x0, 0x0), at
0xf955260f
  [2] tdb_mutex_stats(0xfe240588, 0x162f4, 0x0, 0xff3a4400, 0x0, 0x0),
at 0xfe554bf4
  [3] mutex_lock_internal(0x0, 0x0, 0xfde40000, 0xfe23c000, 0x1,
0x1000), at 0xfe551d3c
  [4] malloc(0x2e694, 0xff352c00, 0xfe1c6794, 0xff353440, 0xff352000,
0x1), at 0xfe1c67ac
  [5] malloc(0x2e681, 0x0, 0x2, 0xffbfdd70, 0x2e681, 0x2e694), at
0xff32f3bc
  [6] operator new(0x2e681, 0xffffffff, 0x13b84, 0xff32ee34,
0xfe66a07c, 0x2e681), at 0xfe65651c
=>[7] TEST::AllocateMem(this = 0xffbffa58, iSize = 190081), line 94 in
"test.h"
  [8] TEST::ProcessRequest(this = 0xffbffa58), line 1320 in "test.cc"
  [9] TEST::OracleCall(this = 0xffbffa58), line 414 in "test.cc"
  [10] main(), line 184 in "main.cc"

here in my code what i'm trying to do is ..
we have to fetch some 200000 bytes of data from Clob field in oracle
table and trying to put in buffer.For this i have kept buffer size to
some 200001 bytes and trying to fetch the data.

In doing this am getting error as above.

The code is like

This function present in test.h:
char *pReturn;
void AllocateReturn(long iSize) { pReturn = new char [iSize]; };

and in test.cc we r calling this by as:
AllocateReturn(200001);

and am deallocating the pointer by
void DeallocateDFReturn()        { delete [] pDFReturn; };

Please advise whether i can have this much of bytes in char pointer??

Regards.

jvramya@mickeyfan.com writes:

> (dbx) showblock -a 0xab0b0

AFAICT from your output, this block has nothing to do with anything.

> t@1 (l@1) signal ILL (illegal opcode) in (unknown) at 0xf9552610
> 0xf9552610:     unimp    0x0
> Current function is UnixDB::AllocateDFReturn
>    94      void AllocateDFReturn(int iSize) { pDFReturn = new char [iSize]; };  /* allocate storage for a magnum display  fmt report */
....
> (dbx) showleaks

Looking for leaks at this point is like "looking for your hair when
your head has been cut off" (translated from Russian) -- pointless.

The most interesting dbx command at that point is "where", but you
didn't do that ... I suspect your crash was in malloc called from
operator new[]. If so, don't do this: "check -leaks"; do this
instead: "check -access".

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

jvramya@mickeyfan.com writes:

>here in my code what i'm trying to do is ..
>we have to fetch some 200000 bytes of data from Clob field in oracle
>table and trying to put in buffer.For this i have kept buffer size to
>some 200001 bytes and trying to fetch the data.

It looks like you corrupt memory somewhere.

>Please advise whether i can have this much of bytes in char pointer??

Yes, easily.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.