i am executing the stored procedure from c++ as below:
dbsqlexec(_bsmdb);
when i execute the stored procedure from command line it gives me proper output.
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)
but in c++ code its giving me core dump.
below is the stored procedure.
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)
The core trace is below:
----------------- 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)
Could anybody please help me finding the problem.....
It looks like your heap is corrupt (it's dying down inside mallocs free-store management code, not in anything DB-related).
Try using a memory-checker tool to identify when the heap gets corrupted (such as Purify if you have it, or IIRC Solaris has a drop-in replacement debugging malloc lib).
This is a C++ bug, unrelated to the stored proc.
Try using libumem, if it is a corruption is due to double delete, it can be easily found. Here is the link.
http://developers.sun.com/solaris/articles/libumem_library.html
You don't even need to recompile the code, just define the variables mentioned in the link in the startup script.
Related
my first attempt in VBA apart from using simple functions; asking for a kick start here:
assume this (part of a) sheet
factor b-count c-count d-count
A2 b2 c2 d2 ...
A3 b3 c3 d3 ...
Assume that these are the first columns and rows A1 to D3, holding numeric values each.
If factor is 1, I want A(N) (column 'A', row N >= 2) to hold the sumproduct of row 1 and row N.
The twist comes when factor is not 1. In that case I want a sumproduct of
count*round(value * factor).
Example:
1.5 2 1 0 4
=myfunc(2) 4 8 11 15
=myfunc(3) 11 20 28 36
=myfunc(4) 29 53 74 94
where myfunc(2) should result in
round(4*1,5)*2+round(8*1,5)*1+round(15*1,5)*4 = 6*2+12*1+23*4 = 12+12+92 = 116, myfunc(3) = 17*2+30+54*4 = 34+30+216 = 280, myfunc(4) = 44*2+80+141*4 = 88+80+564 = 732 etc.
I could just insert a row below each one, multiplying every value with the factor; but I would love something fancier.
basically thought (pun not intended):
col='B'
sum=0
do while (col)(N)>0
sum=sum+(col)(1)*round((col)(N)*A1;0)
col=col+1
loop
A(n)=sum
where (col)(N) refers to the cell in column col and row N.
Not important enough to study the manual; but it would be great if someone can do this off the cuff.
Another point: I have read that custom functions must be stored in the "Standard Library";
but I could not find any mention on HOW to do that. Who will point me to the right manual page?
Go to Tools -> Macros -> Organize Macros -> OpenOffice Basic. Select My Macros -> Standard -> Module 1 (that is what is meant by the Standard library), and press Edit.
Paste the following code.
Function SumProductOfTwoRows(firstColumn As Long, row As Long, firstRow As Long)
'For example: =SUMPRODUCTOFTWOROWS(COLUMN(); ROW(); ROW($A$1))
firstColumn = firstColumn - 1 'column A is index 0
row = row - 1 'row 1 is index 0
firstRow = firstRow - 1 'row 1 is index 0
oSheet = ThisComponent.CurrentController.ActiveSheet
sum = 0
column = firstColumn + 1
factor = oSheet.getCellByPosition(firstColumn, firstRow).getValue()
Do
value = oSheet.getCellByPosition(column, row).getValue()
count = oSheet.getCellByPosition(column, firstRow).getValue()
If value = 0 Then Exit Do
sum = sum + count * CLng(value * factor)
column = column + 1
Loop
SumProductOfTwoRows = sum
End Function
Enter this formula in A2 and drag to fill down to A4.
=SUMPRODUCTOFTWOROWS(COLUMN(); ROW(); ROW($A$1))
The result:
This kind of user-defined function produces an error when re-opening the file. To avoid the error, see my answer at https://stackoverflow.com/a/39254907/5100564.
In my multithread C++ program on Solaris 10 using GNU 2.95.3, I am getting a contention issue while one thread is trying to call the string constructor and other thread is calling a stringbuf constructor, as mentioned below:
One thread is calling
__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCc
i.e.
basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0>>::basic_string(char const *)
Another thread is calling
__9stringbufRCt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0i
i.e.
stringbuf::stringbuf(basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > const &, int)
Eventually both threads lead to allocating space for the string or stringbuf as applicable and results in a contention leading to SIGBUS error.
Any clue?
Do I need to overload malloc or new to be thread-safe or do I need to overload string and stringbuf to ensure thread safety?
I use g++ linker flag as below:
I g++ -g -lclntsh -ldl -lsocket -lrt –lthread
Do I need to add 'g++ -pthread' during compilation? I hope this would add -D_RENENTRANT as well. But Solaris g++ 2.95.3 does not support -pthread
Here's more pstack core output:
core 'core' of 28477:
----------------- lwp# 1 / thread# 1 --------------------
fcb48ac4 __lwp_park (0, 0, fcbb74c4, 1c00, 0, 0) + 14
ff375244 sem_wait (1da56fd8, 1da56c00, 8ea400, 2aae33d0, fcbb49cc, 0) + 20
....
001965f0 _start (0, 0, 0, 0, 0, 0) + 5c
----------------- lwp# 2 / thread# 2 --------------------
fcb4c714 _lwp_kill (a, fed84948, 0, 1, fffffffc, 0) + 8
fdfd6c6c skgesigOSCrash (fc3eea54, fc3ee8fc, ff031460, fef7536c, bc0f4, bc000) + 4c
fe5253a0 kpeDbgSignalHandler (fc3eea54, 2b200cd8, 9e800, a, fc3eee5d, 6060000) + 2f0
fdfd71ac skgesig_sigactionHandler (a, fc3ef6e0, fefef8f8, 0, ff0314a0, fc3eea40) + f0
fcb48b4c __sighndlr (a, fc3ef6e0, fc3ef428, fdfd70bc, 0, 1) + c
fcb3d1f8 call_user_handler (a, 0, 8, 0, fc540200, fc3ef428) + 3b8
fcb3d3cc sigacthandler (a, fc3ef6e0, fc3ef428, 1, fc540200, 0) + 4c
--- called from signal handler with signal 10 (SIGBUS) ---
00608e00 allocate__t24__default_alloc_template2b0i0Ui (20, 20, 9eff80, 1c7be, 2ab11e06, fcbb4f18) +
a4
003cde3c __nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_3RepU
iUi (10, 10, ff000000, 4, fc540200, 861908) + 14
003cef8c create__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_3Re
pUi (2, 2, 2b10d5c8, fcbb5434, fcbb5784, fffc00) + 24
003ee944 replace__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0UiUiP
CcUi (fc3efaf8, 0, ffffffff, 8618a0, 2, 80808080) + 114
006919cc assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCcUi
(fc3efaf8, 8618a0, 2, 0, fc540200, 7164b4) + 24
00666684 assign__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCc (f
c3efaf8, 8618a0, 8ea400, 0, fc5706c0, 0) + 24
005f7868 __t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PCc (fc3efaf
8, 8618a0, 861800, 0, fc3efa90, a4090) + 28
....
----------------- lwp# 3 / thread# 3 --------------------
fcb41818 mutex_lock_impl (fcbb3910, 0, 2dfc0030, fc3beee0, 6, 80808080) + 4
fcad640c malloc (6, 1, d9fd8, 6919cc, fcbb03a8, fcbba518) + 44
003c878c __builtin_vec_new (6, 3, 37, fc3bee38, ff32a888, 4) + 3c
005e16ec __9stringbufRCt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0
i (fc3bee60, fc3bee58, 3, 0, 2b2ab6e8, 20) + 64
...
----------------- lwp# 4 / thread# 4 --------------------
fcb48ac4 __lwp_park (0, 0, fcbb74c4, 1c00, 0, 0) + 14
ff375244 sem_wait (1da56f48, 1da56c00, 1, 0, fc541200, 0) + 20
....
fcb48a20 _lwp_start (0, 0, 0, 0, 0, 0)
Suppose the address for A[10][10] is 40000, double takes 16 bytes, and byte addressing is used, what are the addresses for A[40, 50]?
I am just trying to calculate a simple point in a 2D and just wanted to double check that I plugged in the right values in the equation
BA + [n * (i - LBR) + (j - LBC)] * w
40000 +[10*(40-0)+(50-0)]*16
40000+[10*(40)+(50)]*16
40000+[900]*16 = 54400
Did I apply the formula correctly here? I wasn't sure if i plugged in the right values?
In C++ a 2d array is just an array of arrays, so in A the memory is used for
A[ 0][ 0] A[ 0][ 1] A[ 0][ 2] ... A[ 0][99]
A[ 1][ 0] A[ 1][ 1] A[ 1][ 2] ... A[ 1][99]
...
A[99][ 0] A[99][ 1] A[99][ 2] ... A[99][99]
where each row just follows the previous one in memory.
The address in of an element at (row, col) is
(unsigned char *)(&A[0][0]) + (row*row_size + col) * element_size
In your case you know that the element you are searching is 30 rows lower and 40 elements to the right of given element, therefore the address will be
40000 + ((40 - 10)*100 + (50 - 10)) * 16
totaling to 88640.
You can get to the same result by subtracting the relative address of element (10, 10) from the given address (to find the start of the array) and then by adding the relative address of (40, 50).
The answer is dependent on whether you are using row major ordering or column major ordering. In row major ordering the data is stored row wise. In column major ordering the data is stored column wise. Consider the following 2D array to be stored in memory,
11 22 33
44 55 66
77 88 99
In row major ordering the elements are stored contiguously as 11,22,33,44,55,66,77,88,99.
In column major ordering the the elements are stored contiguously 11,44,77,22,55,88,33,66,99.
The meaning of following equation:
BA + [n * (i - LBR) + (j - LBC)] * w
If you have an array A[n][n] and you know the address of entry A[LBR][LBC] as BA, then address of A[i][j] can be calculated as follows. Assuming n = 6,
00 01 02 03 04 05
10 11 12 13 14 15
20 21 22 23 24 25
30 31 32 33 34 35
40 41 42 43 44 45
50 51 52 53 54 55
Here suppose we know the address of A[2,1] = 1000. We need to calculate the address of A[4,2]. Now to reach [4,2] from [2,1], how many entries will we have to travel? Ofcourse as #Deepu specifies, we can do it two ways, either travel row-wise or column-wise. From the equation it appears that row-wise travel has been selected.
22 to 25 (4)
30 to 35 (6)
40 to 42.(3)
= 13 entries.
Hence address of A[4,2] = 1000 + 13*(numOfbytes per entry)
To verify with the equation,
i - LBR = 4 - 2 = 2.
j - LBC = 2 - 1 = 1.
Hence, n*( i - LBR ) + (j - LBC) = 6*2 + 1 = 13.
We are encountering a randomly occurring segmentation fault on a C/C++ HPUX PA-RISC application RELEASE demo compiled with the HPUX PARISC compiler and linker ACC which loads a HPUX PA_RISC RELEASE shared object sl(i.e. so) compiled and linked with ACC. We do not have access to pmap or HPUX wdb. So we are using HP's proprietary debugger adb. Here is how we use use adb:
$ adb
PA-32 adb ($h help $q quiit)
adb>!cp mdMUReadWriteExample a.out
!
adb>:r
a.out: running (process 10947)
segmentation violation
stopped at 1E3C: STW r3,1416(r1)
At this point it appears the offending instruction is somehow related to the above assembly insruction. Our first question is whether 1416 is in decimal format or hexadecimal format.
Our second question is whether the program counter 1E3C is accurate and can be used to gain further information about the offending C/C++ source line of code/
Our third question is that supposing 1416 is in decimal format , then as shown below register 1($r1) contains 0x40015b90. Using hexadecimal arithmetic 1416(base 10(i.e. hex 0x588)) + 0x40015b90 equals 0x40016118. Next , we use nm to find the shared object library address / C++ mangled symbol associated with 0x40016118.
$ grep -n "4001611" /home/marc/acc3_pa_32bit/cameron_nm.txt
27808:40016118 ? static___soa_RSA_cpp_
27823:40016110 ? static___soa_cDateTime_cpp_
Next we modify our makefile to obtain the combined disassembly -- C++ source code. However, when we search all the 50 generated *.s files we cannot mysteriously find the static___soa_RSA_cpp_. Have we skipped a crucial step here ?
adb>$r
pcoqh 0 1E3F
pcoqt 0 1E43
rp 0 0xC0209793
arg0 0 1 arg1 0 7F7F04FC arg2 0 7F7F050 4 arg3 0 7F7F0540
sp 0 7F7F05D0 ret0 0 0 ret1 0 1 dp 0 40016390
r1 0 40015B90 r3 0 7F7F0000 r4 0 4001591 8 r5 0 3C
r6 0 20 r7 0 3E r8 0 7F7F091 0 r9 0 40015918
r10 0 40031918 r11 0 1E800 r12 0 4001611 8 r13 0 400266A4
r14 0 3F r15 0 3F r16 0 3D r17 0 3D
r18 0 3A r19 0 7B03B764 r20 0 0xA98D4 00 r21 0 7F7F0550
r22 0 0 r31 0 1E2B sar 0 23 sr0 0 0xA98D400
sr1 0 3848400 sr2 0 0 sr3 0 0 sr4 0 0xA98D400
In summary, we are trying to determine if it is possible to find the offending C/C++ source lines which cause this random seg fault. Using Centos Linux and valgrind --tool=memcheck we cannot find any buffer overruns. Thank you.
Good evening, I figured out how to obtain a segmentation fault stack trace with HPUX PA-RISC. 4 steps are required 1) #include "unwind.h" #include "signal.h" 2) define an extern "C" U_STACK_TRACK(int) function prototype 3) in the main function declare a SIGSEGV handler: signal(SIGSEGV,U_STACK_TRACE). 4) In the makefile, link to libcl .Regards , Frank Tzepu Chang
$ mdMUReadWriteExample
( 0) 0xc01fef60 _sigreturn [/usr/lib/libc.2]
( 1) 0xc2f27b90 _ct_7CBigNumFv_2 + 0x88 [./libmdMatchup.sl]
( 2) 0xc2f3c83c RSADecrypt_FPCcN21Pc + 0x24 [./libmdMatchup.sl]
( 3) 0xc2f314ec DecryptLicense_9mdLicenseFPCcPc + 0x44 [./libmdMatchup.sl]
( 4) 0xc2f31280 DecryptDecodeTest_9mdLicenseFPCcT1 + 0x40 [./libmdMatchup.s
l]
( 5) 0xc2f30c3c TestLicense_9mdLicenseFPCc + 0xb4 [./libmdMatchup.sl]
( 6) 0xc2d783bc SetLicenseString_12cBatchDedupeFPCc + 0x5c [./libmdMatchup.
sl]
( 7) 0xc2d6c908 SetLicenseString_13mdMUReadWriteFPCc + 0x90 [./libmdMatchup
.sl]
( 8) 0x0000376c main + 0x68 [./mdMUReadWriteExample]
( 9) 0xc01409f8 _start + 0xa0 [/usr/lib/libc.2]
(10) 0x00002008 $START$ + 0x178 [./mdMUReadWriteExample]
Segmentation fault (core dumped)
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
I am using Dev-C++. It doesn't show any code error, but fails to work.
It works when I try small numbers like 10 or 20
I am working on this problem :
Each new term in the Fibonacci sequence is generated by adding the
previous two terms. By starting with 1 and 2, the first 10 terms will
be:
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...
By considering the terms in the Fibonacci sequence whose values do not
exceed four million, find the sum of the even-valued terms.
#include<stdio.h>
#include<stdlib.h>
int main()
{
const int N=100;
int a=1,b=2,i,t[N],S=0,c,j;
t[0]=1;
t[1]=2;
for(i=2;i<N;i++){
t[i]=t[i-2]+t[i-1];
if(t[i]>4000000)
{
for(j=1;j<=i-1;j++){
c=t[j]%2;
if(c==0){
S=S+t[j];
}
else {
continue;
}}
break;
}
}
printf("%d\n",S);
system("pause");
}
You cannot define a variable size array (T[N]). If you make N const, problem should be solved.
const int N = 3999998;
int T(N);
Also, main should have a return type. Change to "int main()"?
You don't need an array to store all those numbers, you can get away with storing the last two terms in the sequence, since that's all that's need to calculate the next term.
Trying to allocate that much space on the stack is asking for trouble since the stack is a relatively limited resource.
In fact, that exact code entered into gcc on a Linux box gives me a segmentation violation when I try to run it, for precisely that reason.
On top of that, your code is not getting the even valued terms, it's getting every term, and you're getting the first four million values, rather than the values below four million which was specified.
The sort of code you're after would look like this:
#include <stdio.h>
int main (void) {
// Accumulator and terms (acc is zero because first two terms are odd).
int acc = 0, t1 = 1, t2 = 1, t3;
// Continue until next term is 4mil or more.
while ((t3 = t1 + t2) < 4000000) {
// printf ("DEBUG: %d %d %d %s\n", t1, t2, t3,
// ((t3 % 2) == 0) ? "<<" : "");
// Accumulate only even terms.
if ((t3 % 2) == 0) acc += t3;
// Cycle through terms.
t1 = t2; t2 = t3;
}
// Print the accumulated value.
printf ("%d\n", acc);
return 0;
}
And the output:
4613732
If you test that program by un-commenting the debug statement, you see:
DEBUG: 1 1 2 <<
DEBUG: 1 2 3
DEBUG: 2 3 5
DEBUG: 3 5 8 <<
DEBUG: 5 8 13
DEBUG: 8 13 21
DEBUG: 13 21 34 <<
DEBUG: 21 34 55
DEBUG: 34 55 89
DEBUG: 55 89 144 <<
DEBUG: 89 144 233
DEBUG: 144 233 377
DEBUG: 233 377 610 <<
DEBUG: 377 610 987
DEBUG: 610 987 1597
DEBUG: 987 1597 2584 <<
DEBUG: 1597 2584 4181
DEBUG: 2584 4181 6765
DEBUG: 4181 6765 10946 <<
DEBUG: 6765 10946 17711
DEBUG: 10946 17711 28657
DEBUG: 17711 28657 46368 <<
DEBUG: 28657 46368 75025
DEBUG: 46368 75025 121393
DEBUG: 75025 121393 196418 <<
DEBUG: 121393 196418 317811
DEBUG: 196418 317811 514229
DEBUG: 317811 514229 832040 <<
DEBUG: 514229 832040 1346269
DEBUG: 832040 1346269 2178309
DEBUG: 1346269 2178309 3524578 <<
4613732
and, if you add up all the even numbers at the end of those DEBUG lines, you do indeed get the given value.
Two things I notice are that main doesn't have a return type (try int main()) and N is used as an array size but isn't constant.
It's a very common programming error called "Stack overflow". In fact, it's so common that it has named a very popular question and answer site, "Stack Overflow", maybe you have heard about it?
(I've been waiting for being able to give this answer ever since I joined "Stack Overflow"!!!)