Re: "ontape -p" segmentation fault

Hi, this seems to be a new, unknown problem. At least I can't find anything like this in the database of known problems. Please contact IBM Informix Technical Support to report the problem and to get the problem further analysed. Just from the information we have so far I can't deduct what the problem is. It would also be helpful for Tech Support if you can narrow down the circumstances where the problem occurs (vs. where it does not occur). Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management owner-informix-list@iiug.org wrote on 16.06.2005 06:37:40: > > We recently upgraded to IDS9.40UC6. Sometimes "ontape -p" fails with > segmentation fault. > > OS: SunOS osun9071 5.8 Generic_117350-21 sun4u sparc SUNW,Ultra-80 > IDS: 9.40UC6 > > "dbx" produced the following output: > > $ dbx $INFORMIXDIR/bin/ontape > ............. > (dbx) run -p > ............... > ................ > Continue restore? (y/n)y> Do you want to back up the logs? (y/n)n > signal SEGV (no mapping at the fault address) in shm_srv_status at > 0x8987c > 0x0008987c: shm_srv_status+0x007c: ldsh [%g2 + 0x5c0], %g2 > (dbx) where > =>[1] shm_srv_status(0xffbef24c, 0x38, 0xff0cf100, 0x0, 0x21e54, > 0xff0cf24c), at 0x8987c > [2] get_srv_status(0xffbef24c, 0x0, 0x0, 0x0, 0x2, 0x826dc), at > 0x80a00 > [3] connect_for_restore(0x739e, 0x25a308, 0x2, 0x78, 0x21800, > 0x1523560), at 0x826c4 > [4] do_cold_write(0x0, 0x1e4298, 0x1, 0x25a444, 0x15e1c50, 0x1010), > at 0x82448 > [5] sql_phys_write_restore(0x15239a4, 0xffbef594, 0x25a3f8, > 0xffbef590, 0x1523560, 0x15ebac8), at > 0x81e7c > [6] do_cold_phys_restore(0x259e74, 0x1000, 0x1e3810, 0x0, 0x1e3858, > 0x1), at 0x6972c > [7] main(0x1c9c24, 0x25a2b0, 0x1, 0x1e2400, 0x15e1c30, 0x0), at > 0x63368 > (dbx) > > Any ideas as to the cause/work-around? > > Thanks in advance, > > Carl Wu sending to informix-list

The case (# 432299) has been raised to IBM Informix Technical Support several weeks ago and the "dbx" output was provided to the support yesterday before I posted this message. So far I think the problem is random, because within the same shell session if I run another "ontape -p" (still the same backup file) sometimes it may work ! The problem does have a certain level of consistency, when it fails most likely the next "ontape -p" would fail; when it works the next "ontape -p" most likely would work; but not always.