I ran again, this time it points to maloc(), Is this makes sense fro memory
leak?.
==7070== 12 bytes in 1 blocks are definitely lost in loss record 2 of 32
==7070== at 0x40218E4: malloc (vg_replace_malloc.c:195)
==7070== by 0x4D9B6B6: ???
==7070== by 0x4D9BB1A: ???
==7070== by 0x4D95548: ???
==7070== by 0x804DD45: IFDControl (ifdwrapper.c:624)
==7070== by 0x8053D51: SCardControl (winscard.c:1436)
==7070== by 0x8056F8C: ContextThread (winscard_svc.c:455)
==7070== by 0x4033282: start_thread (in /lib/libpthread-2.5.so)
==7070== by 0x4101C6D: clone (in /lib/libc-2.5.so)
==7070==
==7070== 16 bytes in 1 blocks are possibly lost in loss record 3 of 32
==7070== at 0x40218E4: malloc (vg_replace_malloc.c:195)
==7070== by 0x41723B2: usbi_add_pollfd (io.c:2179)
==7070== by 0x41734FF: usbi_io_init (io.c:1015)
==7070== by 0x4170F74: libusb_init (core.c:1484)
==7070== by 0x4028C8E: usb_init (core.c:145)
==7070== by 0x804D6BC: HPEstablishUSBNotifications (hotplug_libusb.c:390)
==7070== by 0x4033282: start_thread (in /lib/libpthread-2.5.so)
==7070== by 0x4101C6D: clone (in /lib/libc-2.5.so)
==7070==
==7070== 54 bytes in 3 blocks are possibly lost in loss record 13 of 32
==7070== at 0x40218E4: malloc (vg_replace_malloc.c:195)
==7070== by 0x417630B: enumerate_device (linux_usbfs.c:733)
==7070== by 0x4176927: op_get_device_list (linux_usbfs.c:854)
==7070== by 0x41706AA: libusb_get_device_list (core.c:605)
==7070== by 0x4028362: usb_find_devices (core.c:579)
==7070== by 0x804D175: HPRescanUsbBus (hotplug_libusb.c:255)
==7070== by 0x804D6C1: HPEstablishUSBNotifications (hotplug_libusb.c:393)
==7070== by 0x4033282: start_thread (in /lib/libpthread-2.5.so)
==7070== by 0x4101C6D: clone (in /lib/libc-2.5.so)
==7070==
==7070== 136 bytes in 1 blocks are possibly lost in loss record 17 of 32
==7070== at 0x4020CC1: calloc (vg_replace_malloc.c:418)
==7070== by 0x40102C8: allocate_dtv (in /lib/ld-2.5.so)
==7070== by 0x401038B: _dl_allocate_tls (in /lib/ld-2.5.so)
==7070== by 0x4033A7F: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.5.so)
==7070== by 0x8051E41: SYS_ThreadCreate (thread_unix.c:81)
==7070== by 0x8055F8C: CreateContextThread (winscard_svc.c:100)
==7070== by 0x804F00A: main (pcscdaemon.c:148)
==7070==
==7070== 143 bytes in 3 blocks are possibly lost in loss record 18 of 32
==7070== at 0x40218E4: malloc (vg_replace_malloc.c:195)
==7070== by 0x4175649: cache_active_config (linux_usbfs.c:610)
==7070== by 0x4176366: enumerate_device (linux_usbfs.c:758)
==7070== by 0x4176927: op_get_device_list (linux_usbfs.c:854)
==7070== by 0x41706AA: libusb_get_device_list (core.c:605)
==7070== by 0x4028362: usb_find_devices (core.c:579)
==7070== by 0x804D175: HPRescanUsbBus (hotplug_libusb.c:255)
==7070== by 0x804D6C1: HPEstablishUSBNotifications (hotplug_libusb.c:393)
==7070== by 0x4033282: start_thread (in /lib/libpthread-2.5.so)
==7070== by 0x4101C6D: clone (in /lib/libc-2.5.so)
==7070==
==7070== 3,944 bytes in 29 blocks are possibly lost in loss record 28 of 32
==7070== at 0x4020CC1: calloc (vg_replace_malloc.c:418)
==7070== by 0x40102C8: allocate_dtv (in /lib/ld-2.5.so)
==7070== by 0x401038B: _dl_allocate_tls (in /lib/ld-2.5.so)
==7070== by 0x4033A7F: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.5.so)
==7070== by 0x4D9B6EC: ???
==7070== by 0x4D9BB1A: ???
==7070== by 0x4D95548: ???
==7070== by 0x804DD45: IFDControl (ifdwrapper.c:624)
==7070== by 0x8053D51: SCardControl (winscard.c:1436)
==7070== by 0x8056F8C: ContextThread (winscard_svc.c:455)
==7070== by 0x4033282: start_thread (in /lib/libpthread-2.5.so)
==7070== by 0x4101C6D: clone (in /lib/libc-2.5.so)
==7070==
==7070== LEAK SUMMARY:
==7070== definitely lost: 12 bytes in 1 blocks
==7070== indirectly lost: 0 bytes in 0 blocks
==7070== possibly lost: 4,293 bytes in 37 blocks
==7070== still reachable: 53,046 bytes in 133 blocks
==7070== suppressed: 0 bytes in 0 blocks
==7070== Reachable blocks (those to which a pointer was found) are not
shown.
==7070== To see them, rerun with: --leak-check=full --show-reachable=yes
==7070==
==7070== For counts of detected and suppressed errors, rerun with: -v
==7070== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 9 from 9)
On Wed, Jan 20, 2010 at 2:11 PM, Vasanta <[email protected]> wrote:
> atlast kill -2 PID worked, I got some log, pointing to common.c file,
> looklike that is culprit.
>
>
> # kill -2 3371
>
> # ==3371== Warning: noted but unhandled ioctl 0x5514 with no size/direction
> hints
>
> ==3371== This could cause spurious value errors to appear.
>
> ==3371== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
> proper wrapper.
>
> ==3371== Invalid read of size 1
>
> ==3371== at 0x4035496: pthread_mutex_destroy (in /lib/libpthread-2.5.so)
>
> ==3371== by 0x4D97B61: CCIDSlotClose (common.c:3144)
>
> ==3371== by 0x4D95D79: IFDHCloseChannel (ifdhandler.c:254)
>
> ==3371== by 0x804E2E8: IFDCloseIFD (ifdwrapper.c:216)
>
> ==3371== by 0x804FB0E: RFUnInitializeReader (readerfactory.c:1075)
>
> ==3371== by 0x80507D3: RFRemoveReader (readerfactory.c:418)
>
> ==3371== by 0x8050A65: RFCleanupReaders (readerfactory.c:1286)
>
> ==3371== by 0x804EFA3: main (pcscdaemon.c:185)
>
> ==3371== Address 0x41b1ee4 is 124 bytes inside a block of size 144 free'd
>
> ==3371== at 0x4021520: free (vg_replace_malloc.c:325)
>
> ==3371== by 0x4D97B47: CCIDSlotClose (common.c:3141)
>
> ==3371== by 0x4D95D79: IFDHCloseChannel (ifdhandler.c:254)
>
> ==3371== by 0x804E2E8: IFDCloseIFD (ifdwrapper.c:216)
>
> ==3371== by 0x804FB0E: RFUnInitializeReader (readerfactory.c:1075)
>
> ==3371== by 0x80507D3: RFRemoveReader (readerfactory.c:418)
>
> ==3371== by 0x8050A65: RFCleanupReaders (readerfactory.c:1286)
>
> ==3371== by 0x804EFA3: main (pcscdaemon.c:185)
>
> ==3371==
>
> ==3371== Invalid read of size 4
>
> ==3371== at 0x403549C: pthread_mutex_destroy (in /lib/libpthread-2.5.so)
>
> ==3371== by 0x4D97B61: CCIDSlotClose (common.c:3144)
>
> ==3371== by 0x4D95D79: IFDHCloseChannel (ifdhandler.c:254)
>
> ==3371== by 0x804E2E8: IFDCloseIFD (ifdwrapper.c:216)
>
> ==3371== by 0x804FB0E: RFUnInitializeReader (readerfactory.c:1075)
>
> ==3371== by 0x80507D3: RFRemoveReader (readerfactory.c:418)
>
> ==3371== by 0x8050A65: RFCleanupReaders (readerfactory.c:1286)
>
> ==3371== by 0x804EFA3: main (pcscdaemon.c:185)
>
> ==3371== Address 0x41b1ee8 is 128 bytes inside a block of size 144 free'd
>
> ==3371== at 0x4021520: free (vg_replace_malloc.c:325)
>
> ==3371== by 0x4D97B47: CCIDSlotClose (common.c:3141)
>
> ==3371== by 0x4D95D79: IFDHCloseChannel (ifdhandler.c:254)
>
> ==3371== by 0x804E2E8: IFDCloseIFD (ifdwrapper.c:216)
>
> ==3371== by 0x804FB0E: RFUnInitializeReader (readerfactory.c:1075)
>
> ==3371== by 0x80507D3: RFRemoveReader (readerfactory.c:418)
>
> ==3371== by 0x8050A65: RFCleanupReaders (readerfactory.c:1286)
>
> ==3371== by 0x804EFA3: main (pcscdaemon.c:185)
>
> ==3371==
>
> ==3371== Invalid write of size 4
>
> ==3371== at 0x40354A8: pthread_mutex_destroy (in /lib/libpthread-2.5.so)
>
> ==3371== by 0x4D97B61: CCIDSlotClose (common.c:3144)
>
> ==3371== by 0x4D95D79: IFDHCloseChannel (ifdhandler.c:254)
>
> ==3371== by 0x804E2E8: IFDCloseIFD (ifdwrapper.c:216)
>
> ==3371== by 0x804FB0E: RFUnInitializeReader (readerfactory.c:1075)
>
> ==3371== by 0x80507D3: RFRemoveReader (readerfactory.c:418)
>
> ==3371== by 0x8050A65: RFCleanupReaders (readerfactory.c:1286)
>
> ==3371== by 0x804EFA3: main (pcscdaemon.c:185)
>
> ==3371== Address 0x41b1ee4 is 124 bytes inside a block of size 144 free'd
>
> ==3371== at 0x4021520: free (vg_replace_malloc.c:325)
>
> ==3371== by 0x4D97B47: CCIDSlotClose (common.c:3141)
>
> ==3371== by 0x4D95D79: IFDHCloseChannel (ifdhandler.c:254)
>
> ==3371== by 0x804E2E8: IFDCloseIFD (ifdwrapper.c:216)
>
> ==3371== by 0x804FB0E: RFUnInitializeReader (readerfactory.c:1075)
>
> ==3371== by 0x80507D3: RFRemoveReader (readerfactory.c:418)
>
> ==3371== by 0x8050A65: RFCleanupReaders (readerfactory.c:1286)
>
> ==3371== by 0x804EFA3: main (pcscdaemon.c:185)
>
> ==3371==
>
> winscard.c:309:SCardConnect() Reader OMNIKEY CardMan 3821 00 00 Not Found
>
> conntrack v0.9.13 (conntrack-tools): connection tracking table has been
> emptied.
>
> ==3371== Thread 4:
>
> ==3371== Invalid free() / delete / delete[]
>
> ==3371== at 0x4021520: free (vg_replace_malloc.c:325)
>
> ==3371== by 0x413C0ED: ??? (in /lib/libc-2.5.so)
>
> ==3371== by 0x413BC71: ??? (in /lib/libc-2.5.so)
>
> ==3371== by 0x401D4C3: _vgnU_freeres (vg_preloaded.c:62)
>
> ==3371== by 0x9: ???
>
> ==3371== by 0x805626D: ContextThread (winscard_svc.c:137)
>
> ==3371== by 0x4033282: start_thread (in /lib/libpthread-2.5.so)
>
> ==3371== by 0x4101C6D: clone (in /lib/libc-2.5.so)
>
> ==3371== Address 0x416d2c0 is not stack'd, malloc'd or (recently) free'd
>
> ==3371==
>
> ==3371==
>
> ==3371== HEAP SUMMARY:
>
> ==3371== in use at exit: 101,859 bytes in 501 blocks
>
> ==3371== total heap usage: 63,030 allocs, 62,530 frees, 14,386,509 bytes
> allocated
>
> ==3371==
>
>
>
> On Wed, Jan 20, 2010 at 2:09 PM, Ashley Pittman <[email protected]>wrote:
>
>>
>> When run under valgrind the process wont have the name "pcscd" but rather
>> will be called "valgrind" as you sent in your previous mail, either that or
>> kill the pid directly rather than using killall.
>>
>> Does SIGTERM correctly kill the process when it's running outside of
>> valgrind?
>>
>> Ashley,
>>
>> On 20 Jan 2010, at 18:58, Vasanta wrote:
>>
>> killall command should send SIGTERM, but I tried to send either killall
>> or "kill -1 3371", neither work.
>>
>> # killall pcscd
>> killall: pcscd: no process killed
>> # killall /pfrm2.0/bin/pcscd
>> killall: /pfrm2.0/bin/pcscd: no process killed
>> #
>>
>>
>>
>>
>> On Wed, Jan 20, 2010 at 1:53 PM, Ashley Pittman <[email protected]>wrote:
>>
>>>
>>> On 20 Jan 2010, at 18:34, Vasanta wrote:
>>>
>>> > Ashely / Tom:
>>> > Initially this pcscd runs, then it forks, that is why PID is diff, I
>>> run with trace-children=yes, didn't get much info since program is keep
>>> running
>>>
>>> This is what you'd expect, errors will be reported as it runs, leak
>>> checking will be performed when it exits.
>>>
>>> > I don't know how can I forcefully exit, the main function in this below
>>> link for pcscdaemon.c file. also I tried --foreground, gives error for that
>>> option. any idea can I force exit pcscd?
>>>
>>> This is entirely down to pscsd, how do you normally shut it down?
>>> Sending SIGTERM is often the best way to stop deamons unless they implement
>>> their own exit case.
>>>
>>> Ashley,
>>
>>
>>
>>
>
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
