You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Ricky Chan (JIRA)" <ji...@apache.org> on 2011/05/20 10:39:47 UTC
[jira] [Created] (TS-793) the freelist dump function are not
showing the correct values
the freelist dump function are not showing the correct values
-------------------------------------------------------------
Key: TS-793
URL: https://issues.apache.org/jira/browse/TS-793
Project: Traffic Server
Issue Type: Bug
Components: Cleanup, Core
Affects Versions: 2.1.7, 2.0.1
Environment: Linux Debian 5.0 (2.6.26 Kernel) on AMD64.
Reporter: Ricky Chan
Priority: Trivial
I'm tracking a memory leak in 2.0.1 (possibly exists in latest versions too) and I am relying on the freelist_dump from when a USR1 signal is sent to gather information to determine where a memory leak is happening (I lose 5G a day).
I notice that it started showing negative numbers pretty quickly when one of the lists was using more than 2G, so I looked in the code and found fprintf was using %d, considering the storage for allocated, type_size,count are unsigned 32 bit integers, that explained the zero.
I have patched my code to use unsigned and unsigned long long to avoid me losing information in these dumps.
I checked at this is still the case in at least 2.1.7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-793) the freelist dump function are not
showing the correct values
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-793:
-----------------------------
Fix Version/s: 2.1.9
> the freelist dump function are not showing the correct values
> -------------------------------------------------------------
>
> Key: TS-793
> URL: https://issues.apache.org/jira/browse/TS-793
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
> Affects Versions: 2.1.7, 2.0.1
> Environment: Linux Debian 5.0 (2.6.26 Kernel) on AMD64.
> Reporter: Ricky Chan
> Assignee: Leif Hedstrom
> Priority: Trivial
> Labels: Debug
> Fix For: 2.1.9
>
> Attachments: ink_queue.patch
>
>
> I'm tracking a memory leak in 2.0.1 (possibly exists in latest versions too) and I am relying on the freelist_dump from when a USR1 signal is sent to gather information to determine where a memory leak is happening (I lose 5G a day).
> I notice that it started showing negative numbers pretty quickly when one of the lists was using more than 2G, so I looked in the code and found fprintf was using %d, considering the storage for allocated, type_size,count are unsigned 32 bit integers, that explained the zero.
> I have patched my code to use unsigned and unsigned long long to avoid me losing information in these dumps.
> I checked at this is still the case in at least 2.1.7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-793) the freelist dump function are not
showing the correct values
Posted by "Ricky Chan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037427#comment-13037427 ]
Ricky Chan commented on TS-793:
-------------------------------
Sorry, my apologises, I just checked against 2.1.7 (and 2.1.6) and indeed it has already been changed from %d -> %u. Not sure what I was validating it against.
I guess the %llu is still valid for when two unsigned 32 bit integers are multiplied together %u may not be big enough to represent the true value (e.g. my production servers have values larger than what can be fitted in %u).
> the freelist dump function are not showing the correct values
> -------------------------------------------------------------
>
> Key: TS-793
> URL: https://issues.apache.org/jira/browse/TS-793
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
> Affects Versions: 2.1.7, 2.0.1
> Environment: Linux Debian 5.0 (2.6.26 Kernel) on AMD64.
> Reporter: Ricky Chan
> Assignee: Leif Hedstrom
> Priority: Trivial
> Labels: Debug
> Fix For: 2.1.9
>
> Attachments: ink_queue.patch
>
>
> I'm tracking a memory leak in 2.0.1 (possibly exists in latest versions too) and I am relying on the freelist_dump from when a USR1 signal is sent to gather information to determine where a memory leak is happening (I lose 5G a day).
> I notice that it started showing negative numbers pretty quickly when one of the lists was using more than 2G, so I looked in the code and found fprintf was using %d, considering the storage for allocated, type_size,count are unsigned 32 bit integers, that explained the zero.
> I have patched my code to use unsigned and unsigned long long to avoid me losing information in these dumps.
> I checked at this is still the case in at least 2.1.7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-793) the freelist dump function are not
showing the correct values
Posted by "Ricky Chan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ricky Chan updated TS-793:
--------------------------
Attachment: ink_queue.patch
This is for 2.0.1 (but the same issue appears in 2.1.7)
> the freelist dump function are not showing the correct values
> -------------------------------------------------------------
>
> Key: TS-793
> URL: https://issues.apache.org/jira/browse/TS-793
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
> Affects Versions: 2.1.7, 2.0.1
> Environment: Linux Debian 5.0 (2.6.26 Kernel) on AMD64.
> Reporter: Ricky Chan
> Priority: Trivial
> Labels: Debug
> Attachments: ink_queue.patch
>
>
> I'm tracking a memory leak in 2.0.1 (possibly exists in latest versions too) and I am relying on the freelist_dump from when a USR1 signal is sent to gather information to determine where a memory leak is happening (I lose 5G a day).
> I notice that it started showing negative numbers pretty quickly when one of the lists was using more than 2G, so I looked in the code and found fprintf was using %d, considering the storage for allocated, type_size,count are unsigned 32 bit integers, that explained the zero.
> I have patched my code to use unsigned and unsigned long long to avoid me losing information in these dumps.
> I checked at this is still the case in at least 2.1.7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-793) the freelist dump function are not
showing the correct values
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom reassigned TS-793:
--------------------------------
Assignee: Leif Hedstrom
> the freelist dump function are not showing the correct values
> -------------------------------------------------------------
>
> Key: TS-793
> URL: https://issues.apache.org/jira/browse/TS-793
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
> Affects Versions: 2.1.7, 2.0.1
> Environment: Linux Debian 5.0 (2.6.26 Kernel) on AMD64.
> Reporter: Ricky Chan
> Assignee: Leif Hedstrom
> Priority: Trivial
> Labels: Debug
> Fix For: 2.1.9
>
> Attachments: ink_queue.patch
>
>
> I'm tracking a memory leak in 2.0.1 (possibly exists in latest versions too) and I am relying on the freelist_dump from when a USR1 signal is sent to gather information to determine where a memory leak is happening (I lose 5G a day).
> I notice that it started showing negative numbers pretty quickly when one of the lists was using more than 2G, so I looked in the code and found fprintf was using %d, considering the storage for allocated, type_size,count are unsigned 32 bit integers, that explained the zero.
> I have patched my code to use unsigned and unsigned long long to avoid me losing information in these dumps.
> I checked at this is still the case in at least 2.1.7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-793) the freelist dump function are not
showing the correct values
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037224#comment-13037224 ]
Leif Hedstrom commented on TS-793:
----------------------------------
Hmmm, are you sure this is an issue in v2.1.7? I checked the code, and it was changed to %u in SVN commit #982072, which was on TS-400 on Aug 3 2010.
http://svn.apache.org/viewvc/trafficserver/traffic/trunk/libinktomi%2B%2B/ink_queue.cc?r1=982072&r2=982071&pathrev=982072
Please let me know what I'm missing.
> the freelist dump function are not showing the correct values
> -------------------------------------------------------------
>
> Key: TS-793
> URL: https://issues.apache.org/jira/browse/TS-793
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
> Affects Versions: 2.1.7, 2.0.1
> Environment: Linux Debian 5.0 (2.6.26 Kernel) on AMD64.
> Reporter: Ricky Chan
> Assignee: Leif Hedstrom
> Priority: Trivial
> Labels: Debug
> Fix For: 2.1.9
>
> Attachments: ink_queue.patch
>
>
> I'm tracking a memory leak in 2.0.1 (possibly exists in latest versions too) and I am relying on the freelist_dump from when a USR1 signal is sent to gather information to determine where a memory leak is happening (I lose 5G a day).
> I notice that it started showing negative numbers pretty quickly when one of the lists was using more than 2G, so I looked in the code and found fprintf was using %d, considering the storage for allocated, type_size,count are unsigned 32 bit integers, that explained the zero.
> I have patched my code to use unsigned and unsigned long long to avoid me losing information in these dumps.
> I checked at this is still the case in at least 2.1.7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira