To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=85381
Issue #|85381
Summary|Heap corruption bug in dmake
Component|tools
Version|OOH680m2
Platform|PC
URL|
OS/Version|Windows, all
Status|UNCONFIRMED
Status whiteboard|
Keywords|
Resolution|
Issue type|PATCH
Priority|P3
Subcomponent|dmake
Assigned to|mh
Reported by|tml
------- Additional comments from [EMAIL PROTECTED] Fri Jan 18 21:47:31 +0000
2008 -------
There is a heap corruption bug in dmake that occurs only on Cygwin. Look at the
function gen_path_list_string(). This function takes a list of pathnames in
Cygwin (Unix) form and turns them into a single string of pathnames in Windows
form separated by spaces. Look at the code where Cygwin paths are turned into
Windows paths:
tpath = DO_WINPATH(cell->datum);
if( tpath == cell->datum ) {
len=cell->len;
}
else {
/* ... but only if DO_WINPATH() did something. */
len = strlen(tpath);
if( len > slen_rest ) {
/* We need more memory. As DOS paths are usually shorter than the
* original cygwin POSIX paths (exception mounted paths) this should
* rarely happen. */
The condition (len > slen_rest) is bogus. slen_rest is irrelevant here. What len
should be tested against is the length of the original Cygwin pathname,
cell->len. After that change, and correspondingly for the same reason changing
the subexpression len-slen_rest to len->cell-len a couple of lines below, we
then also notice that there is no use for the slen_rest variable at all. Also,
looking at the following code where the result buffer is reallocated:
/* Get more than needed. */
slen += slen + len-cell->len + 128;
if((result = realloc( result, (unsigned)(slen*sizeof(char)) ) ) ==
NULL)
No_ram();
we see some odd things. Firstly, slen += slen + len-cell->len + 128. Wtf?
Clearly what is meant is slen += len-cell->len + 128. However, there is no real
reason for that "extra" 128. It seems that the persons behind this code were
aware that there is something wrong with it, but didn't quite know what, so they
throw in an "extra" 127 bytes and hope for the best. (Alas, this doesn't help
for the crash I observed as the problem was that this "We need more memory"
branch isn't taken in the first place even if needed.) There is no need for that
"more than needed", just doing slen += (len-cell->len) + 1 works fine.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
