View Issue Details

IDProjectCategoryView StatusLast Update
0005546JEDI VCL00 JVCL Componentspublic2011-09-21 14:10
ReporterBig PapaAssigned Toobones 
Status resolvedResolutionfixed 
Product VersionDaily / GIT 
Target VersionFixed in Version3.45 
Summary0005546: TJvHidPnPInfo is freed twice
DescriptionSometimes (if a HID device can't be opened) the TJvHidPnPInfo is freed twice.

If the device can't be opened an exception is raised in the constructor of TJvHidDevice:
        raise EControllerError.CreateRes(@RsEDeviceCannotBeOpened);

Then the destructor is called which calls free on the previously set FPnPInfo field:

The second free is called in TJvHidDeviceController.DeviceChange.FillInList after the exception is caught:
        PnPInfo := TJvHidPnPInfo.Create(PnPHandle, DevData, PChar(@FunctionClassDeviceData.DevicePath));
            // create HID device object and add it to the device list
              HidDev := TJvHidDevice.CtlCreate(PnPInfo, Self);
              // ignore device if unreadable but still free used memory
!!!! PnPInfo.Free;

In earlier versions the PnPInfo.Free; statement in the FillInList procedure is missing (and all works well ;))
TagsNo tags attached.



2011-04-24 16:04

reporter   ~0018528

I would like to vote +1 for this issue as it is causing an error for some of my users


2011-04-24 16:09

reporter   ~0018529

Couldn't it just be...

if PnPInfo <> nil then


2011-04-25 13:57

reporter   ~0018530



... might be best in both Free's to be cleaner

Big Papa

2011-04-27 19:23

reporter   ~0018531

FreeAndNill won't work because two pointers to the same class are freed (if one is set to nil the other isn't)

The best practice whould be to determine which class is the owner of the pnpInfo ans so is responsible for the destruction.
Because the TJvHidDevice destroys the pnpInfo I think the ownership of the pnpInfo goes from TJvHidDeviceController to the TJvHidDevice which is after the constructor call responsible for the destruction of pnpInfo.

=> so i just deleted the PnPInfo.Free; line in the TJvHidDeviceController.DeviceChange.FillInList function.


2011-05-04 20:10

reporter   ~0018534

You are right. I don't care how they fix it as long as they fix it as I have verified it has solved my users issues.


2011-06-07 17:58

administrator   ~0018632

Yes, this looks stupid


2011-06-08 16:10

administrator   ~0018685

This is now fixed in SVN

Issue History

Date Modified Username Field Change
2011-04-06 15:08 Big Papa New Issue
2011-04-24 16:04 Melloware Note Added: 0018528
2011-04-24 16:09 Melloware Note Added: 0018529
2011-04-25 13:57 Melloware Note Added: 0018530
2011-04-27 19:23 Big Papa Note Added: 0018531
2011-05-04 20:10 Melloware Note Added: 0018534
2011-06-07 17:58 obones Note Added: 0018632
2011-06-07 17:58 obones Status new => acknowledged
2011-06-08 16:10 obones Note Added: 0018685
2011-06-08 16:10 obones Status acknowledged => resolved
2011-06-08 16:10 obones Fixed in Version => Daily / SVN
2011-06-08 16:10 obones Resolution open => fixed
2011-06-08 16:10 obones Assigned To => obones
2011-09-21 14:10 obones Fixed in Version Daily / SVN => 3.45