ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
After the comment about valgrind, I ran the program using gdb and found that p pointer is pointing to an invalid memory address.
Code:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000410a8c in build_tag (x=6 '\006', p=0xffffffffbfffbb0e <Address 0xffffffffbfffbb0e out of bounds>) at ber.c:160
Your gdb result makes it most likely that a bad value of ucPacket was passed into build_tag. It is the kind of bad value that most often occurs because code incorrectly assumes sizeof(int)==sizeof(void*) as I guessed earlier.
On x86_64 sizeof(int)==4 and sizeof(void*)==8
Trusting the code in your first post plus this new info, it seems like the definition of ucbuild_oid would be a better place to look than the definition of build_tag
Edit:
Quote:
I think I posted this before a few posts back.
I didn't spot it. (The thread is a bit messy). So I figured out it (definition of build_tag) wasn't actually what I wanted to see right before I confirmed that by finally seeing it.
The ucbuild_oid() function is definately the problem. When I comment it out, I don't get the segmentation fault for address out of bounds. I commented out build_len() function separately, but address out of bounds still happens.
The ucPacket address goes from [0x7feffcaff] to [0xfffffffffeffcaff] on the return from this function. I used gdb to step through the function, but still haven't pin-pointed the cause.
[Update] Yikes. Adding 1 to sidp increases sidp by 80 on Linux and 40 on Solaris.
Code:
/* Call to ucbuild_oid with the values */
ucPacket = ucbuild_oid(4278168392, 10, "215");
uchar* ucbuild_oid ( register sid* x, register uint l, register uchar* p ){
register ulong *sidp = x + l, val;
register uchar *op = p;
/* sidp = 4278168472 based on first parm x*/
while( l-- ){
val = *--sidp;
*--p = val & 0x7f;
while( val >>= 7 )
*--p = val | 0x80;
}
return build_len( op - p, p );
}
Last edited by SeymourButts; 01-16-2010 at 09:12 PM.
I expect ulong is defined in a way that is 32 bits in your Solaris build but 64 bits in x86_64.
If you get no error for sidp=x+l then sid must be compatible with ulong.
I don't know enough about what you left out nor how all the pieces you quoted fit together to be sure, but the values don't look big enough for 32 bit vs. 64 bit to make a difference in val. If it did make a difference, you would be using more bytes in the target buffer to split val into 7 bit chunks for x86_64 than you did for Solaris.
One possibility from that or other causes is that you are overflowing the buffer (in reverse) and clobbering whatever happens to be stored before it.
You earlier quoted unsigned char buffer [4096];
Are you sure 4096 is enough for whatever you are storing in that buffer.
Quote:
Originally Posted by SeymourButts
Yikes. Adding 1 to sidp increases sidp by 80 on Linux and 40 on Solaris.
Was that a typo or confusion? Either way a good example of why you shouldn't use the single letter l as the name of a variable.
You said l has the value 10. So you are adding 10 times sizeof(ulong) to the actual value of the pointer. Why would that be surprising?
Quote:
Originally Posted by smeezekitty
Code:
ucbuild_oid(4278168392, 10, "215");
WTF?! i just relized you are passing a litteral value as a pointer!
I assume that was quoted from information displayed by the debugger, not from the source code. So no, it is not a literal passed as a pointer. It is the run time value of a pointer displayed as a literal.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339
Rep:
Quote:
Originally Posted by johnsfine
What data type is a sid?
I expect ulong is defined in a way that is 32 bits in your Solaris build but 64 bits in x86_64.
If you get no error for sidp=x+l then sid must be compatible with ulong.
I don't know enough about what you left out nor how all the pieces you quoted fit together to be sure, but the values don't look big enough for 32 bit vs. 64 bit to make a difference in val. If it did make a difference, you would be using more bytes in the target buffer to split val into 7 bit chunks for x86_64 than you did for Solaris.
One possibility from that or other causes is that you are overflowing the buffer (in reverse) and clobbering whatever happens to be stored before it.
You earlier quoted unsigned char buffer [4096];
Are you sure 4096 is enough for whatever you are storing in that buffer.
Look closly:That code is assuming the memory location will always be:
Code:
4278168392
4278168392 is likely not memory that belongs to the program!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.