Glen, I'm not sure it's the scope of mdb-discuss list, but In most cases SIGILL means something goes wrong with return address in the stack so after ret function jumps to wrong location. Check array bounds etc inside ixwsru & icgcud
Glen Gunselman wrote: > I have a third party app that is core dumping. Some days I get 8 to 10 > dumps. No one is complaining (except me) about any problems using the > application. This has been going on for several months (so I can forget > trying to identify any application changes that might point to the source). > > I have a crontab set up to check /var/core once an hour and run the following > mdb commands on any new dump files (the files are moved to a directory on an > NFS mount to keep /var from filling): > > mdb $bin $i <<EOA > > =nn"** Core file status **" > ="------------------------" > ::status > > =nn"** Thread stack **" > ="----------------------" > ::stack > > =nn"** regs **" > ="----------------------" > ::regs > > =nn"** Shared objects **" > ="----------------------" > ::objects > > EOA > > ::status all most always shows (sometimes the signal is SIGBUS, sometimes > SIGSEGV) > > ** Core file status ** > ------------------------ > debugging core file of f90webm (32-bit) from kermit > executable file: /u01/app/oracle/product/10gASforms/9.0.4/bin/f90webm > initial argv: > /u01/app/oracle/product/10gASforms/9.0.4/bin/f90webm server > webfile=HTTP-0,0,0, > threading model: multi-threaded > status: process terminated by SIGILL (Illegal Instruction) > > > ::stack almost always starts (ends?) with: > > ** Thread stack ** > ---------------------- > 0x1638adc(3, 1814490, ffbfa32c, 0, 0, 0) > ixwsru+0x114(12703e8, ffbfa394, 0, 0, 0, 0) > icgcud+0xe8(12703e8, ffbfa3f8, 100, 0, ffbfa464, 0) > ifzterm+0x1dc(12703e8, 1, 1, e, 81010100, ff0000) > siehjmpterm+0x2cc(e, 0, ffbfa698, 0, 0, 0) > libthread.so.1`__sighndlr+0xc(e, 0, ffbfa698, 1fab48, 0, 0) > libthread.so.1`call_user_handler+0x234(e, 0, ffbfa698, 0, 0, 0) > libthread.so.1`sigacthandler+0x64(e, 0, ffbfa698, 0, 0, 0) > libc.so.1`_read+0xc(6, 1290388, 400, 400, 7ffffff2, fece625c) > ixhgr_GenRead+0x6c(12703e8, 127dd78, 1290388, 400, ffbfab84, 0) > ixhrdh_ReadHeader+0x38(12703e8, 127dd78, 1290368, 10e3f54, 0, 0) > ixhhsm_HTTPStateMachine+0x250(12703e8, 127dd78, 1, fffffffe, 4, 0) > > Have talked to the third party support people and they ... (well, don't have > anything usefull to add). > > Without any other information, is there something I could get from the dump > that would help with making the error more "observable"? (Well, at least to > the casual observer [me]) > > The server is a V490 running Solaris 9 4/04. The application is an Oracle AS > based ERP. > > Thanks for any ideas/insight/wisdom, > Glen Gunselman > > > This message posted from opensolaris.org > _______________________________________________ > mdb-discuss mailing list > mdb-discuss at opensolaris.org -- Dmitry Samersoff J2SE Sustaining team, SPB02 * There will come soft rains ...
