Extension causes segmentation fault -- suggestions on troubleshooting?

[R. Steve McKown]

Hello,

I'm writing a C extension for cygwin python to access a vendor supplied DLL 
that allows one to set the general purpose IO (gpio) pins of the Silicon 
Labs' cp2103 USB/serial chip.  We communicate to the device using the 
vendor's virtual com port driver, but the gpio pins allow us access to other 
functions, like resetting the device and initiating a firmware download.  The 
DLL provides a function, CP210xRT_WriteLatch which sets the gpio pins.  It 
accepts the HANDLE of the open device's com port, a bit mask, and a bit data 
field to perform its task.

Note: I load the DLL dynamically within the extension's init function.  Even 
though the DLL functions are C, apparently the vendor did not use "extern C 
{", as the functions have C++-like decorations (seen via 'nm' on the .lib 
file) and cygwin's gcc linker generates symbol not found errors when linking 
to the provided .lib.  Dynamically loading the library works.  FWIW, the DLL 
is said to be compiled via VC++ 6.0.  Also using the vendor supplied .h file.

The extension code, python test program, stackdump output and program run 
output are included in the attached tgz file for reference.

Th extension accepts a file descriptor to an open serial port, uses the cygwin 
get_osfhandle() function to get the corresponding HANDLE, calls the DLL 
function, then returns.  When run, python core dumps somewhere between the 
return statement in the extension function and the python program statement 
following the call to the extension function.  The gpio bits are set 
correctly.

If I comment out the call to the DLL function within the extension, no core 
dump.  Obviously, the gpio bits are not set in this case.

If I do not open the com port in the python program, but instead call 
CreateFile/CloseFile within the extension itself and using the HANDLE 
provided by CreateFile to call the DLL function, the gpio bits are set and no 
core dump.  I could live with this approach if Python could have the com port 
open when it calls the extension.  When I try this, the extension's call to 
CreateFile to open the com port always fails, presumably because the serial 
module opens it in some manner that doesn't allow sharing...?

Being relatively new to Python, I'm hoping someone can see an obvious mistake, 
or suggest some strategies to troubleshoot this problem.

Thank you for your time,
Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cp210x_rt.tgz
Type: application/x-tgz
Size: 2771 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20061206/5a7acffa/attachment.bin>