Skip to Content

ASE 16 stack trace - Replicate to a table with self foreign key

Hi,

I'm having a problem with my upgrade to ASE 16 PL03 on my HP-UX server. A stack trace is generated when replicating data in warm-standy environment to a table with a self foreign key.

00:0002:00000:00205:2016/06/25 15:15:35.03 kernel Current process (0x1ff0100) infected with signal 11 (SIGSEGV)

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel Address 0x4000000002559340 (_ZN6LeSarg7mapSargEP4sdesssssP5rangeP4sarg+0x2180), siginfo (code, address) = (2, 0x0000000000000024)

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel **** Saved signal context (0xc00000010c6e7000): ****

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel **** Itanium signal context ****

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel IP: 4000000002559340

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel reason: 81

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel **** Itanium General Registers ****

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel NAT: 3840000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR1: 0x600000000071e710

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR2: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR3: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR4: 0x0000000000008000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR5: 0xc000000179989c34

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR6: 0xc00000017997e3e4

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR7: 0x000000000000011c

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR8: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR9: 0xc000000000000ca1

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR10: 0x400000000257a720

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR11: 0xfe4f8ffe1ffbe743

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR12: 0xc00000010c6ebe60

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR13: 0x6000000000b570e0

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR14: 0xc0000001b17c6254

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR15: 0x00000000c0000001

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR16: 0x00000000c0000001

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR17: 0xc0000001b17a1274

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR18: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR19: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR20: 0xc0000001b17c6244

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR21: 0x0000000000000024

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR22: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR23: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR24: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR25: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR26: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR27: 0xc0000001b17c6244

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR28: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR29: 0x0000000000000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR30: 0x00000000b17c6240

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel GR31: 0xc000000100000000

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel **** Itanium Floating Point Registers ****

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR2: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR3: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR4: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR5: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR6: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR7: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR8: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR9: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR10: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR11: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR12: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR13: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR14: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR15: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR16: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR17: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR18: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR19: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR20: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR21: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR22: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR23: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR24: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR25: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR26: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR27: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR28: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel FR29: -2.000002

00:0002:00000:00205:2016/06/25 15:15:35.04 kernel **** end of signal context ****

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel ************************************

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel SQL causing error :

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel Current statement number: 2 Current line number: 1

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel ************************************

00:0002:00000:00205:2016/06/25 15:15:35.05 server SQL Text:

00:0002:00000:00205:2016/06/25 15:15:35.05 server SQL Text: update se_funcionario set codigo_perfil=@@@V0_INT, funcionario=@@@V1_INT, nivel_autoridad=@@@V2_INT, oficina=@@@V3_VCHAR1, departamento=@@@V4_VCHAR1, codigo_usuario=@@@V5_VCHAR1, clave=@@@V6_VCHAR1, expiracion_clave=@@@V7_VCHAR1, rango=@@@V8_VCHAR1, fecha_estado=NULL , fecha_registro=@@@V9_VCHAR1, indicador_activo=@@@V10_VCHAR1, funcionario_registra=NULL , grupo_base_datos=@@@V11_VCHAR1, numero_acta_trabajo=@@@V12_VCHAR1, numero_recibo_trabajo=NU

00:0002:00000:00205:2016/06/25 15:15:35.05 server SQL Text: , numero_prefirmado_trabajo=@@@V13_INT, monto_trabajo=@@@V14_NUME199, consecutivo_persona=NULL , correo_funcionario=NULL , codigo_perfil_compras=NULL , nive_autoriza=NULL , region=@@@V15_VCHAR1, nivel_autoriza=NULL , codigo_perfil_postula=NULL , codigo_region=NULL , codigo_perfil_contituyen=NULL , codigo_perfil_viatico_reg=NULL , codigo_pla_direcciones_reg=NULL , codigo_perfil_viaticos=NULL , codigo_direccion_viaticos=NULL , indicador_flujo=NULL

00:0002:00000:00205:2016/06/25 15:15:35.05 server SQL Text: codigo_perfil_independiente=NULL , codigo_partido=NULL , codigo_perfil_carnet=NULL , oficina_carnet=NULL , multiple_carnet=NULL , duprapext=NULL where funcionario=@@@V16_INT

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel curdb = 6 tempdb = 2 pstat = 0x10100 p2stat = 0x101000

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel p3stat = 0x10800 p4stat = 0x0 p5stat = 0x8 p6stat = 0x11 p7stat = 0x10000

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel lasterror = 0 preverror = 0 transtate = 0

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel curcmd = 197 program = DBISQL

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel extended error information: hostname: ADMSRV10 login: sa

00:0002:00000:00205:2016/06/25 15:15:35.05 kernel pc: 0x40000000061d66f0 pcstkwalk+0xf0(0x0000000001ff0100, 0x0000000000000002, 0x000000000000270f, 0x0000000000000000, 0x0000000000000000)

00:0002:00000:00205:2016/06/25 15:15:35.06 kernel pc: 0x40000000061d5560 ucstkgentrace+0xb70(0x0000000001ff0100, 0x0000000000000001, 0x600000000071e710, 0xc000000000000a1a, 0x400000000343b770)

00:0002:00000:00205:2016/06/25 15:15:35.07 kernel pc: 0x40000000061ce2a0 ucbacktrace+0x160(0x0000000000000000, 0xffffffffffffffff, 0x600000000071e710, 0xc000000000000898, 0x4000000006279d30)

00:0002:00000:00205:2016/06/25 15:15:35.07 kernel pc: 0x400000000343b770 $cold_terminate_process+0x2b30(0x000000000000000b, 0x60000000006fe1f8, 0xc00000000054e2e0, 0x600000000071e710, 0xc000000000000187)

00:0002:00000:00205:2016/06/25 15:15:35.07 kernel pc: 0x4000000006279d30 kisignal+0x580(0xc00000010c6e7000, 0x000000020000000b, 0xc00000010c6e6e10, 0x000000000000000b, 0x60000000006fe1f8)

00:0002:00000:00205:2016/06/25 15:15:35.07 kernel pc: 0xe0000001201cb440 <signal handler called>(0xc0000001b17c6250, 0x00000000b17c6240, 0x0000000000000004, 0xc000000100000000, 0x0000000000000000)

00:0002:00000:00205:2016/06/25 15:15:35.08 kernel pc: 0x4000000002559340 _ZN6LeSarg7mapSargEP4sdesssssP5rangeP4sarg+0x2180(0xc0000001b17c62d0, 0xc000000179994cc0, 0x0000000000000004, 0x0000000000000007, 0x0000000000000012)

00:0002:00000:00205:2016/06/25 15:15:35.09 kernel pc: 0x400000000257a720 _ZN11LeSargArray10setupSargsEP4sdesssssP5range+0x180(0xc0000001b17c6350, 0xc0000001b182e9a0, 0x600000000071e710, 0xc000000000000b99, 0x400000000263ba50)

00:0002:00000:00205:2016/06/25 15:15:35.09 kernel pc: 0x40000000025e53c0 _ZN8LeScanOp9_LeOpOpenER7ExeCtxt+0x360(0xc0000001b17c6a10, 0xc0000001b182e9a0, 0x600000000071e710, 0xc000000000000a1b, 0x40000000027f6470)

00:0002:00000:00205:2016/06/25 15:15:35.10 kernel pc: 0x400000000263ba50 _ZN13LeScalarAggOp9_LeOpOpenER7ExeCtxt+0x2b0(0xc0000001b17c6d60, 0xc0000001b17a87c0, 0xc0000001b182e9a0, 0x0000000000000000, 0x600000000071e710)

00:0002:00000:00205:2016/06/25 15:15:35.10 kernel pc: 0x40000000027f6470 _ZN12LeSQFilterOp11runSubEvalsEP7LeEvalsR7ExeCtxti+0x3d0(0xc0000001b17c6d60, 0xc0000001b182e9a0, 0x600000000071e710, 0xc0000000000011a8, 0x400000000773d550)

00:0002:00000:00205:2016/06/25 15:15:35.11 kernel pc: 0x40000000028794d0 _ZN12LeSQFilterOp9_LeOpNextER7ExeCtxt+0x2e0(0xc0000001b17c70b0, 0xc0000001b182e9a0, 0x600000000071e710, 0xc000000000000206, 0x4000000007735a40)

00:0002:00000:00205:2016/06/25 15:15:35.11 kernel pc: 0x400000000773d550 _ZN12LeRIFilterOp14_LeOpDefRINextER7ExeCtxt+0x1150(0xc0000001b17c70b0, 0xc0000001b182e9a0, 0xc000000000000a16, 0x4000000002599d40, 0xc0000001b17c70b0)

00:0002:00000:00205:2016/06/25 15:15:35.12 kernel pc: 0x4000000007735a40 _ZN12LeRIFilterOp9_LeOpNextER7ExeCtxt+0x80(0xc0000001b17c70b0, 0xc0000001b182e9a0, 0x600000000071e710, 0xc00000000000132b, 0x4000000002607c90)

00:0002:00000:00205:2016/06/25 15:15:35.13 kernel pc: 0x4000000002599d40 _ZN10LeOperator8LeOpNextER7ExeCtxt+0x160(0xc0000001b14ea420, 0xc0000001b182e9a0, 0x600000000071e710, 0xc000000000000c1a, 0x40000000025f0580)

00:0002:00000:00205:2016/06/25 15:15:35.13 kernel pc: 0x4000000002607c90 _ZN7LeDMLOp10_LeOpCloseER7ExeCtxt+0x16a0(0xc00000018d86aaa0, 0x0000000000000005, 0x600000000071e710, 0xc000000000000896, 0x40000000025ef510)

00:0002:00000:00205:2016/06/25 15:15:35.14 kernel pc: 0x40000000025f0580 _ZN9LeEmittOp10_LeOpCloseER7ExeCtxt+0x260(0xc0000001b182e9a0, 0x600000000071e710, 0xc000000000000e24, 0x40000000025a6650, 0x0000000004000800)

00:0002:00000:00205:2016/06/25 15:15:35.14 kernel pc: 0x40000000025ef510 LePlanClose+0x290(0x60000000006fd9c8, 0xc00000010c6ec2a0, 0x0000000000000001, 0xc0000001b182e9a0, 0x0000000000000000)

00:0002:00000:00205:2016/06/25 15:15:35.15 kernel pc: 0x40000000025a6650 exec_lava+0x2340(0x4000000002533910, 0x600000000071e710, 0xfe4f8ffe1ffb904d, 0xc00000010c6ec164, 0xc00000010c6ec164)

00:0002:00000:00205:2016/06/25 15:15:35.15 kernel pc: 0x40000000025de3a0 s_execute+0x4950(0x4000000002530090, 0x600000000071e710, 0xfe4f8ffe1ffbe107, 0xc000000000000ea5, 0xc00000017997e110)

00:0002:00000:00205:2016/06/25 15:15:35.16 kernel pc: 0x4000000002533910 sequencer+0xa80(0x40000000025dfb10, 0xfe4f8ffe1ffb6007, 0x0000000000000000, 0xc000000000002c60, 0x600000000070bef0)

00:0002:00000:00205:2016/06/25 15:15:35.16 kernel pc: 0x4000000002530090 execproc+0xb10(0x4000000002533910, 0x600000000071e710, 0xfe4f8ffe1ffb6041, 0xc00000010c6ecfa4, 0xc00000010c6ecfa4)

00:0002:00000:00205:2016/06/25 15:15:35.17 kernel pc: 0x40000000025dfb10 s_execute+0x60c0(0x40000000027e3c00, 0x600000000071e710, 0xfe4f8ffe1ffb025d, 0xc000000000000a9d, 0xc00000017997e110)

00:0002:00000:00205:2016/06/25 15:15:35.17 kernel pc: 0x4000000002533910 sequencer+0xa80(0xc00000017998c968, 0x600000000071e710, 0xc000000000001634, 0x4000000002517d80, 0xfe4f8ffe1ffb8019)

00:0002:00000:00205:2016/06/25 15:15:35.18 kernel pc: 0x40000000027e3c00 tdsrecv_language+0x500(0x4000000001ce5710, 0x600000000071e710, 0xfe4f8ffe1ffb655b, 0x0000000000000000, 0xc000000000000308)

00:0002:00000:00205:2016/06/25 15:15:35.18 kernel pc: 0x4000000002517d80 conn_hdlr+0x37e0(0xc0000001059fbbd0, 0xc0000001059fbbd0, 0xc00000012ee0f2b0, 0x600000000071e710, 0xc00000000000048a)

00:0002:00000:00205:2016/06/25 15:15:35.18 kernel end of stack trace, spid 205, kpid 33489152, suid 1

ddl of the self foreign key :

-----------------------------------------------------------------------------

-- Dependent DDL for Object(s)

-----------------------------------------------------------------------------

alter table database.dbo.se_funcionario

add constraint fk_se_funcionario_registra FOREIGN KEY (funcionario_registra) REFERENCES database.dbo.se_funcionario(funcionario)

go

As you can see it references itself.

Any comment will be appreciated.

Regards,

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • Posted on Jun 28, 2016 at 03:47 PM

    Generally speaking, stack traces are usually best addressed by opening a case with tech support.

    ---------------

    In the meantime ...

    Your description makes it sound like a replicated transaction is causing the stack trace.

    However, the stack trace says the offending command was submitted from the DBISQL application. [I would expect a stack trace from a replicated transaction to show the offending command being submitted by the Repserver application.]

    Did a replicated txn (submitted by a repserver) cause a stack trace ... and you're using DBISQL to reproduce the stack trace?

    The SQL in question seems to show that the statement cache is enabled. Have you tried to (temporarily) disable statement cache ('statement cache size' = 0; 'literal autoparam' = 0), then submit the UPDATE again to see if the stack trace still occurs? Alternatively, issue 'set statement_cache off', 'go', 'update ...'. [The objective being to see if the stack trace is related to the self-RI, an issue with statement cache, or perhaps a combination of the self-RI and statement cache.]

    Add a comment
    10|10000 characters needed characters exceeded

    • Thanks Mark,

      Yes, I used DBISQL to run the query from the replication server that was causing the stack traces.

      i firegure that was the self foreign because eliminating the column from the update query it ran ok.

      I did disable the statement cache and restarting the server but the stack trace remains when foreign key is there... so i had to eliminate it.

      Regards

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.