дамп ядра внутри хранимой процедуры - PullRequest
Новая
       15

дамп ядра внутри хранимой процедуры

0 голосов
/ 15 февраля 2012

я выполняю хранимую процедуру из c ++, как показано ниже: 

  dbsqlexec(_bsmdb);

когда я выполняю хранимую процедуру из командной строки, это дает мне правильный вывод. 

2> declare @apicounter int
exec CapApi_CountTgRxObjects @apicounter output, 'subnetwork="NETSim_BAG",bsc=3> "BAG01",site="RS8000#0",mo="RXOTG-0",%'
4> go
(return status = 0)

Return parameters:


 -----------
           9


(1 row affected)

но в коде c ++ это дает мне дамп ядра.

ниже - хранимая процедура. 

CREATE PROCEDURE CapApi_CountTgRxObjects (@count_out int output,@tgdn_in varchar
         (200))
AS
BEGIN
    declare @likeGE varchar(200),
            @likeLT varchar(200),
            @rc int

    /*
    ** Build the simulated like strings
    */
    exec @rc =
 CapApi_likeFix @likeStr=@tgdn_in, @likeGE=@likeGE OUT, @likeLT=@likeLT OUT

    if (@rc != 0)
    begin
        return 1
    end

    /*
    ** Execute the Worker procedure
    */
    exec CapApi_CountTgRxObjectsW @count_out=@count_out OUT, @tgdn_GE=@like
 GE, @tgdn_LT=@likeLT

    /*
    ** Normal exit point
    */
    return 0
END




(3 rows affected)
(return status = 0)

Основной след ниже: 

-----------------  lwp# 1 / thread# 1  --------------------
 fcb16576 t_splay  (140e6958) + 1f
 fcb16454 t_delete (140e6958) + 2a
 fcb1618e realfree (140e6918) + 58
 fcb16797 cleanfree (0) + 44
 fcb15cb3 _malloc_unlocked (8, 83df9d0, 140e68c8, fc4df378, 802a988, fc44ee9b) + ad
 fcb15bdc malloc   (4) + 34
 fc44ee9b comn_malloc (4) + 1b
 fc438012 dbsvretval (83df9d0) + 3f6
 fc4369c5 dbsqlok  (83df9d0) + 115
 fc436668 dbsqlexec (83df9d0, 0) + 30
 fec1c19f __1cICACCC_tgWCheck_BTS_capabilities6FrnGcna_Mo_ri_v_ (802c24c, 821cc40) + 3ff
 fec1d4a2 __1cICACCC_tgOPerform_checks6FrnGcna_Mo_ri_v_ (802c24c, 821cc40) + 272
 fec16953 __1cICACCC_tgNDirect_checks6FrknGvector4CpnGcna_MO___rikikb_v_ (802c2b8, 821cc40, 2, 0, 0, 0) + 3c3
 feaa760d __1cJCACCC_bscNDirect_checks6FpnTCACCC_consist_check_rknGvector4CpnGcna_MO___rikikbrfkf_v_ (821cc28, 802c4b0, 821cc40, 2, 0, 821cc54) + 64d
 fe9b25ae __1cTCACCC_consist_checkJcheck_bsc6M_v_ (821cc28, 0) + 17e
 fe9ac7de __1cTCACCC_consist_checkNcheck_perform6M_i_ (821cc28, 0) + 14e
 fe9acd2b __1cTCACCC_consist_checkFcheck6M_i_ (821cc28, 0) + 9b
 0805c656 main     (2, 802d1ac, 802d1b8, 802d1a0) + 11a6
 08051ebd _start   (2, 802d95c, 802d97d, 0, 802d993, 802d9cb) + 7d
-----------------  lwp# 2 / thread# 2  --------------------
 fcb7ae55 ___nanosleep (78) + 15
 fd52a4c2 run      (821f668) + 1a2
 fcb7875b _thr_setup (fc040200) + 4e
 fcb78a60 _lwp_start (fc040200, 0, 0, fbffeff8, fcb78a60, fc040200)

Может кто-нибудь, пожалуйста, помогите мне найти проблему .....

Ответы [ 2 ]

0 голосов
/ 20 февраля 2012

Попробуйте использовать libumem, если это повреждение из-за двойного удаления, его легко найти.Вот ссылка.http://developers.sun.com/solaris/articles/libumem_library.html

Вам даже не нужно перекомпилировать код, просто определите переменные, указанные в ссылке в скрипте запуска.

0 голосов
/ 15 февраля 2012

Похоже, что ваша куча повреждена (она умирает внутри malloc кода управления свободным хранилищем, а не в каких-либо связанных с БД).

Попробуйте использовать инструмент проверки памяти, чтобы определить, когдаПовреждена куча (например, Purify, если она у вас есть, или в IIRC Solaris есть отладочная замена, вставляющая malloc lib).

Это ошибка C ++, не связанная с хранимым процессом.

...