Bug 67666 - Correction for DEBUG_MEM usage
Summary: Correction for DEBUG_MEM usage
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-02 11:45 UTC by Thomas Freitag
Modified: 2013-08-08 18:34 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
new function gstrdup (2.49 KB, text/plain)
2013-08-02 11:45 UTC, Thomas Freitag
Details
upload it as patch intead of plain text (2.49 KB, patch)
2013-08-02 11:48 UTC, Thomas Freitag
Details | Splinter Review
use copyString where memory is freed with gfree (936 bytes, patch)
2013-08-06 10:07 UTC, Thomas Freitag
Details | Splinter Review

Description Thomas Freitag 2013-08-02 11:45:25 UTC
Created attachment 83530 [details]
new function gstrdup

If the poppler sources are compiled with DBEUG_MEM, the gfree call gives an error message if the memory is not allocated by gmalloc. But a very few routines uses strdup to allocate and copy strings, and later use gfree to free the allocated memory, which gives an error message if compiled with DEBUG_MEM.
One sample for this behaviour is Dict::Dict(Dict* dictA).
The attached patch introduces the new function gstrdup and use it everywhere instead of strdup.
Comment 1 Thomas Freitag 2013-08-02 11:48:17 UTC
Created attachment 83532 [details] [review]
upload it as patch intead of plain text
Comment 2 Albert Astals Cid 2013-08-02 17:30:51 UTC
Makes sense,  you think we should appy it to both 0.24 and master or only 0.24? Arguably "it is a bug", but only happens on "special debug mode", so i'm undecided if only master would be enough.
Comment 3 Thomas Freitag 2013-08-04 09:42:22 UTC
I think, master is sufficient. I only run into that error because I compile my window version with DEBUG_MEM with VisualC Debug settings, and I think, it's rarely used.
Comment 4 Albert Astals Cid 2013-08-04 18:45:35 UTC
Actaully i just saw we have something called copyString(), should we just use that? or rename that? or kill it and move it to the new gstrdup?
Comment 5 Thomas Freitag 2013-08-05 07:47:15 UTC
(In reply to comment #4)
> Actaully i just saw we have something called copyString(), should we just
> use that? or rename that? or kill it and move it to the new gstrdup?

Sorry, I missed the function copyString, otherwise I would have probably used it. On the other hand: having a gstrndup (instead of strndup) but a copyString (instead of strdup) is a little bit confusing, isn't it? Therefore I would vote for kill copyString (just used in Object.h) and use gstrdup instead.
Comment 6 Albert Astals Cid 2013-08-05 17:58:57 UTC
You need to improve your grepping skills ;-)
copyString is used in loooooooots of files, not only Object.h

Since it's actually an xpdf function i'd prefer if we use that to keep merging with a future possible xpdf 3.04 easier.

Do you want to upload a patch with copyString for those places or shall I?
Comment 7 Thomas Freitag 2013-08-06 10:07:31 UTC
Created attachment 83708 [details] [review]
use copyString where memory is freed with gfree

(In reply to comment #6)
> You need to improve your grepping skills ;-)

Upps, grep copyString */*.h is not the best way to find all occurences of copyString :-)


> copyString is used in loooooooots of files, not only Object.h
> 
> Since it's actually an xpdf function i'd prefer if we use that to keep
> merging with a future possible xpdf 3.04 easier.
> 
> Do you want to upload a patch with copyString for those places or shall I?

Here it is. I just replace the call of strdup with copyString where the pointer is freed with gfree().
Comment 8 Albert Astals Cid 2013-08-08 18:34:55 UTC
Pushed


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.