in reply to Really Odd Bug With LWP and Device::SerialPort

In Windows (Win32::SerialPort), a buffer overflow warning: "Win32::API::Call: parameter 2 had a buffer overflow at C:/Perl/site/lib/Win32API/CommPort.pm line 220"

It means something in C land went writing off the end of a scalar string. That is a bug in Win32::SerialPort or Win32API::CommPort. Now why would WriteFile the perl sub, which is a read-only function, get something written into the buffer, within, or beyond C malloc block bounds? IDK.

On further research, this sub https://metacpan.org/source/BBIRTH/Win32-SerialPort-0.22/lib/Win32API/CommPort.pm#L1667 looks totally wrong. The buffer passed to WriteFile is lexical, and will be freed at the end of the write_bg sub (but before write_done returns control, which is when the async buffer is released from the Windows Kernel because the async IO operation ended), which is incompatible with asynchronous IO. The scalar should have been inside that object as a reference, and write_done should undef the ref to free the buffer. I did not run any code.
  • Comment on Re: Really Odd Bug With LWP and Device::SerialPort

Replies are listed 'Best First'.
Re^2: Really Odd Bug With LWP and Device::SerialPort
by kschwab (Vicar) on Aug 11, 2013 at 05:33 UTC
    Makes sense, though it's odd that if I use Device::Serial port on a linux box instead, I get basically the same bug. No Win32 errors, of course, but nothing goes out the serial port. Device::SerialPort and Win32::SerialPort only share a common outside interface...the code itself is quite different.
[reply]
      I see this issues on strawberry perl 5.16.2.1 and Win32::API::CommPort 0.20 and Perl Tk both with a separate thread for comms and without it. Error manifests only on certain writes (not always) and solution described in the first post does fix the problem. This definitely requires a fix, as it costs days to debug... And probably is relevant to many people not being vocal...
[reply]

In Section Seekers of Perl Wisdom