Stacktrace can be produced when the log of a database is completely full

It is understood that the transaction log filled up but that shouldn’t cause a stacktrace to be produced. Whenever a stacktrace is produced, people can get a bit excited about it. (not good)

sequence of events:

  1. repserver goes down
  2. database tran log fills up
  3. thousands of “uppause: No free alarms available.” messages
  4. thousands of stacktraces

I’ve opened a case with Sybase so ASE won’t produce the stacktrace as it can confuse people as to thinking that the stacktrace is the problem not the fact that the log is filled up.
So, ignore this particular stacktrace when the transaction log is full.

00:00000:01527:2006/09/26 10:53:11.36 kernel uasetalarm: no more alarms available
01:00000:01527:2006/09/26 10:53:11.36 kernel uppause: No free alarms available.
01:00000:01527:2006/09/26 10:53:11.36 kernel ************************************
01:00000:01527:2006/09/26 10:53:11.36 kernel SQL causing error : insert into table_x (err_date, 01:00000:01527:2006/09/26 10:53:11.36 kernel ************************************
01:00000:01527:2006/09/26 10:53:11.36 server SQL Text:
01:00000:01527:2006/09/26 10:53:11.36 kernel curdb = 4 tempdb = 2 pstat = 0x10100
01:00000:01527:2006/09/26 10:53:11.36 kernel lasterror = 3475 preverror = 0 transtate = 1
01:00000:01527:2006/09/26 10:53:11.36 kernel curcmd = 195 program =
01:00000:01527:2006/09/26 10:53:11.40 kernel pc 0x88027ed ucbacktrace+0x89(0x0,0x1,0x93674d0,0x56e869d4,0x0)
01:00000:01527:2006/09/26 10:53:11.40 kernel pc 0x81b3f99 terminate_process+0xbd1(0x0,0xffffffff,0x93674d0,0x40974e34,0x835ea5f)
01:00000:01527:2006/09/26 10:53:11.40 kernel pc 0x820c0a5 close_network+0x19(0x93674d0,0x1cc,0x40974ee0,0x83aceed,0xfffffffc)
01:00000:01527:2006/09/26 10:53:11.42 kernel pc 0x835ea5f do_pause_on_fatal_xls_error+0x9b(0xfffffffc,0x1,0x7,0x10f,0x93674d0)
01:00000:01527:2006/09/26 10:53:11.42 kernel pc 0x83aceed plc__flush+0x775(0x4f6a7608,0x130000,0x0,0x93674d0,0x38b2eb20)
01:00000:01527:2006/09/26 10:53:11.42 kernelpc 0x83ac29e xls_preflush+0xda(0x5e52f034,0x130000,0x0,0x93674d0,0x5e52f034)
01:00000:01527:2006/09/26 10:53:11.42 kernel pc 0x8373695 finishlog+0x241(0x5e52f034,0x2,0x93674d0,0x1,0x56e869d4)
01:00000:01527:2006/09/26 10:53:11.42 kernel pc 0x832162exact__endxact+0x1a2(0x5e52f034,0x2b,0x93674d0,0x5e52f034,0x56e869d4)
01:00000:01527:2006/09/26 10:53:11.42 kernel pc 0x8321270 xact__commitxact+0x3c4(0x5e52f034,0x93674d0,0x8327dd4,0x1,0x84ea52a)
01:00000:01527:2006/09/26 10:53:11.42 kernel pc 0x8320e36 xact__commit_local+0xea(0x93674d0,0x1,0x4097568c,0x84dde11,0x40975380)
01:00000:01527:2006/09/26 10:53:11.42 kernel pc 0x8327dd9 xact_commit+0x41(0x40975380,0x93674d0,0x56e869d4,0x3,0x20202020)
01:00000:01527:2006/09/26 10:53:11.44 kernel pc 0x84dde11 s_execute+0x539d(0x93674d0,0x0,0x56e86901,0x0,0x61645f72)
01:00000:01527:2006/09/26 10:53:11.44 kernel pc 0x84f2e85 sequencer+0xf79(0x6c3c0000,0x93674d0,0x0,0x56e86901,0x81c749e)
01:00000:01527:2006/09/26 10:53:11.44 kernel pc 0x81e33e5 tdsrecv_language+0x2ed(0x0,0x0,0x0,0x0,0x0)
01:00000:01527:2006/09/26 10:53:11.44 kernel pc 0x81f2ec5 conn_hdlr+0x2809(0x3a6,0x40975b88,0x895eed31,0x0,0x0)
01:00000:01527:2006/09/26 10:53:11.44 kernel pc 0x8244c47 ex_cleanup(0x0,0x0,0x0,0x3c770900,0x420)
01:00000:01527:2006/09/26 10:53:11.45 kernel pc 0x895eed31 init_dummy+0x809584b1(0x0,0x3c770900,0x420,0x1,0x5374616b)
01:00000:01527:2006/09/26 10:53:11.45 kernel end of stack trace, spid 1527, kpid 4719647, suid 6578
Share Button