2012-02-15 3 views
0

я выполнение хранимой процедуры из 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 @[email protected]_in, @[email protected] OUT, @[email protected] OUT 

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

    /* 
    ** Execute the Worker procedure 
    */ 
    exec CapApi_CountTgRxObjectsW @[email protected]_out OUT, @[email protected] 
GE, @[email protected] 

    /* 
    ** 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) 

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

ответ

0

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

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

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

+0

Но когда я прокомментирую вызов выполнения хранимой процедуры. и жесткий код выходных переменных. Нет никакого ядра dump.so, почему это ошибка C++? – Vijay

+0

Ошибка C++ - это все, что испортило кучу в первую очередь. Если вы закомментируете сохраненный вызов proc и просто вызовите 'malloc (4)' вместо этого, он там сбой? Если это так, вам все равно нужно найти то, что повредило вашу кучу в первую очередь, как я уже сказал. В противном случае наиболее вероятным исключением является то, что куча повреждена _inside_ 'dbsqlexec', возможно, потому что' _bsmdb' недействителен или уже освобожден. – Useless

0

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

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

Смежные вопросы