• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 196
  • Last Modified:

Perl API problems?

I'm working on a binary ecryption library for perl. The library written in C but my problem is rather perl API related so I'm posting here.
The library receives a few parameters, does the encryption and returns the encrypted data. Before the encryption takes place the required buffer size for the encrypted data is calculated. When this value (nOutDataLen) is calculated sv_setpvn is used to allocate the buffer for the result. The whole context is

     /* set up our output buffer */
     sv_setpvn(svOutData, "", nOutDataLen);

     /* get the pointer to the buffer */
     pOutData = (unsigned char*)SvPV(svOutData, nOutDataLen);
     /* now try and create the blob */
     bRet = EncryptData(pRemoteKey,
                    pLightData,
                    nLightDataLen,
                    pHeavyData,
                    nHeavyDataLen,
                    pOutData,
                    &nOutDataLen);

This code worked fine so far but it turned out recently that if the calculated result length is too long the code is failing. I did some sanity check and found that if nOutDataLen >= 7361 then the library crashes but working fine if nOutDatalength <= 7360.
According to the debug session sv_setpvn is failing.

Interestingly the code is working fine when the compiler optimalisations (used /O1) are turned off.

I have used Win32 for the investigation but the library has similar problems on Linux.

Any thoughts?

TIA

Zoltan Magyar
0
zmagyar
Asked:
zmagyar
  • 2
1 Solution
 
jmcgOwnerCommented:
This line is probably key:

 > Interestingly the code is working fine when the compiler optimalisations (used /O1) are turned off.

One of the things that can cause the compiler to make the wrong decisions when optimizing is "aliasing". Without knowing anything more about your code, I would be most concerned about passing the address of nOutDataLen in your call to EncryptData. If the idea is for the routine to pass back a new, shorter length, you would, I think, want to pass a copy of nOutDataLen rather than the original.

Either that or you just have the calling sequence wrong and it should be nOutDataLen that is being passed rather than its address.
0
 
zmagyarAuthor Commented:
Thanks for your comment.

> I would be most concerned about passing the address of
> nOutDataLen in your call to EncryptData. If the idea is
> for the routine to pass back a new, shorter length, you
> would, I think, want to pass a copy of nOutDataLen
> rather than the original.

Unluckily the code doesn't get to this point during the execution. The perl API is crashing in sv_setpvn.

Meanwhile I did a debug build of perl and tried to check a bit further. AFAICS there is some mess with the memory allocation. malloc is failing allocating the memory. :-(

0
 
jmcgOwnerCommented:
The Perl API documentation for sv_setpv says that the string must be a null-terminated string, but does not include that restriction for sv_setpvn. That makes me think that, instead of the "" string you have used, that you must use a string or buffer with at least nOutDataLen bytes in it as the source or else you run the risk that it'll try copying bytes from non-mapped memory.

It could well be that what you really want to do is malloc the space for the output buffer yourself and call sv_usepvn() on it.
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now