I've had to remove mingw from my regression testing since it's creating .lib files which cause bjam to "except" when running the tests. I can see _what_ the problem is, but not _why_ it is. Here's the call stack (well what appears relevant... the top when the error occurs) bjam.exe!_chvalidator(int c=-128, int mask=8) Line 56 + 0x2a bytes C
bjam.exe!file_archscan(char * archive=0x02fd82c0, void (void *,
char *, int, long)* func=0x00412400, void * closure=0x00500458) Line 266 + 0x36 bytes C bjam.exe!timestamp(char * target=0x02fd86e0, long * time=0x0097ab8c) Line 164 + 0x15 bytes C bjam.exe!search(char * target=0x00b3247c, long * time=0x0097ab8c, char * * another_target=0x00000000) Line 130 + 0xd bytes C bjam.exe!bind_explicitly_located_target(void * xtarget=0x0097ab64, void * data=0x00000000) Line 165 + 0x14 bytes C bjam.exe!hashenumerate(hash * hp=0x004ffd08, void (void *, void *)* f=0x0040f9d0, void * data=0x00000000) Line 251 + 0xe bytes C bjam.exe!bind_explicitly_located_targets() Line 176 + 0x12 bytes C bjam.exe!make(int n_targets=1, const char * * targets=0x0012f6bc, int anyhow=0) Line 128 C bjam.exe!main(int argc=0, char * * argv=0x003213c0, char * * arg_environ=0x00321470) Line 434 + 0x15 bytes C Here's a memory dump of the variable "name"...note the two \n\n near the end (just before the FD FD FD FD) and NO trailing '\0' to stop the strlen() 0x02FD9EA8 65 78 65 63 75 74 69 6f 6e 5f 6d 6f 6e 69 74 6f execution_monito 0x02FD9EB8 72 2e 6f 62 6a 2f 0a 75 6e 69 74 5f 74 65 73 74 r.obj/.unit_test 0x02FD9EC8 5f 70 61 72 61 6d 65 74 65 72 73 2e 6f 62 6a 2f _parameters.obj/ 0x02FD9ED8 0a 75 6e 69 74 5f 74 65 73 74 5f 6c 6f 67 2e 6f .unit_test_log.o 0x02FD9EE8 62 6a 2f 0a 75 6e 69 74 5f 74 65 73 74 5f 6d 6f bj/.unit_test_mo 0x02FD9EF8 6e 69 74 6f 72 2e 6f 62 6a 2f 0a 75 6e 69 74 5f nitor.obj/.unit_ 0x02FD9F08 74 65 73 74 5f 72 65 73 75 6c 74 2e 6f 62 6a 2f test_result.obj/ 0x02FD9F18 0a 75 6e 69 74 5f 74 65 73 74 5f 73 75 69 74 65 .unit_test_suite 0x02FD9F28 2e 6f 62 6a 2f 0a 73 75 70 70 6c 69 65 64 5f 6c .obj/.supplied_l 0x02FD9F38 6f 67 5f 66 6f 72 6d 61 74 74 65 72 73 2e 6f 62 og_formatters.ob 0x02FD9F48 6a 2f 0a 0a fd fd fd fd 80 00 1a 00 dd 00 dd 06 j/..ýýýý...Ý.Ý. 0x02FD9F58 d8 f6 fd 02 78 01 32 00 dd dd dd dd dd dd dd dd Øöý.x.2.ÝÝÝÝÝÝÝÝ Further debug information available upon request. It would be nice to get the mingw tests back in my testing...this system has a fair chunk of free time right now. Oh, as for the white space in the report? I have NO idea were to even start looking. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
At Monday 2004-09-27 02:38, you wrote:
Victor A. Wagner Jr. wrote:
Oh, as for the white space in the report? I have NO idea were to even start looking.
Could you make your bjam.log available somewhere?
ftp://rudbek.com/pub/boost/bjam.log I've modified my script to put it there each time it runs
Thanks,
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
I've had to remove mingw from my regression testing since it's creating .lib files which cause bjam to "except" when running the tests. I can see _what_ the problem is, but not _why_ it is. Here's the call stack (well what appears relevant... the top when the error occurs)
bjam.exe!_chvalidator(int c=-128, int mask=8) Line 56 + 0x2a bytes C
bjam.exe!file_archscan(char * archive=0x02fd82c0, void (void
*, char *, int, long)* func=0x00412400, void * closure=0x00500458) Line 266 + 0x36 bytes C bjam.exe!timestamp(char * target=0x02fd86e0, long * time=0x0097ab8c) Line 164 + 0x15 bytes C bjam.exe!search(char * target=0x00b3247c, long * time=0x0097ab8c, char * * another_target=0x00000000) Line 130 + 0xd bytes C bjam.exe!bind_explicitly_located_target(void * xtarget=0x0097ab64, void * data=0x00000000) Line 165 + 0x14 bytes C bjam.exe!hashenumerate(hash * hp=0x004ffd08, void (void *, void *)* f=0x0040f9d0, void * data=0x00000000) Line 251 + 0xe bytes C bjam.exe!bind_explicitly_located_targets() Line 176 + 0x12 bytes C bjam.exe!make(int n_targets=1, const char * * targets=0x0012f6bc, int anyhow=0) Line 128 C bjam.exe!main(int argc=0, char * * argv=0x003213c0, char * * arg_environ=0x00321470) Line 434 + 0x15 bytes C
Here's a memory dump of the variable "name"...note the two \n\n near the end (just before the FD FD FD FD) and NO trailing '\0' to stop the strlen()
0x02FD9EA8 65 78 65 63 75 74 69 6f 6e 5f 6d 6f 6e 69 74 6f execution_monito 0x02FD9EB8 72 2e 6f 62 6a 2f 0a 75 6e 69 74 5f 74 65 73 74 r.obj/.unit_test 0x02FD9EC8 5f 70 61 72 61 6d 65 74 65 72 73 2e 6f 62 6a 2f _parameters.obj/ 0x02FD9ED8 0a 75 6e 69 74 5f 74 65 73 74 5f 6c 6f 67 2e 6f .unit_test_log.o 0x02FD9EE8 62 6a 2f 0a 75 6e 69 74 5f 74 65 73 74 5f 6d 6f bj/.unit_test_mo 0x02FD9EF8 6e 69 74 6f 72 2e 6f 62 6a 2f 0a 75 6e 69 74 5f nitor.obj/.unit_ 0x02FD9F08 74 65 73 74 5f 72 65 73 75 6c 74 2e 6f 62 6a 2f test_result.obj/ 0x02FD9F18 0a 75 6e 69 74 5f 74 65 73 74 5f 73 75 69 74 65 .unit_test_suite 0x02FD9F28 2e 6f 62 6a 2f 0a 73 75 70 70 6c 69 65 64 5f 6c .obj/.supplied_l 0x02FD9F38 6f 67 5f 66 6f 72 6d 61 74 74 65 72 73 2e 6f 62 og_formatters.ob 0x02FD9F48 6a 2f 0a 0a fd fd fd fd 80 00 1a 00 dd 00 dd 06 j/..ýýýý...Ý.Ý. 0x02FD9F58 d8 f6 fd 02 78 01 32 00 dd dd dd dd dd dd dd dd Øöý.x.2.ÝÝÝÝÝÝÝÝ
Further debug information available upon request. It would be nice to get the mingw tests back in my testing...this system has a fair chunk of free time right now.
http://tinyurl.com/5vwpf seems to indicate that we can fix it by changing if( !isspace(*endname) && *endname != '\\' && *endname != '/' ) to if( (unsigned)(c + 1) > 256 || !isspace(*endname) && *endname != '\\' && *endname != '/' ) in tools/build/jam_src/filent.c Could you try making that change and letting us know how it works out? (BTW, this also indicates that you're using a debug build of bjam. Maybe we should change things so people get a release build? could speed up testing) Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
At Monday 2004-09-27 05:19, you wrote:
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
I've had to remove mingw from my regression testing since it's creating .lib files which cause bjam to "except" when running the tests. I can see _what_ the problem is, but not _why_ it is. Here's the call stack (well what appears relevant... the top when the error occurs) [deleted]
http://tinyurl.com/5vwpf seems to indicate that we can fix it by changing
if( !isspace(*endname) && *endname != '\\' && *endname != '/' )
to
if( (unsigned)(c + 1) > 256 || !isspace(*endname) && *endname != '\\' && *endname != '/' )
nope, nor does: if( (unsigned)(*endname + 1) > 256 || !isspace(*endname) && *endname != '\\' && *endname != '/' ) the problem just gets postponed and eventually someone tries to access 0xfdfdfdfd however, changing the malloc back several lines to be one larger, then putting a '\0' at the end _does_ seem to fix it. Checked into CVS.
in tools/build/jam_src/filent.c
Could you try making that change and letting us know how it works out?
(BTW, this also indicates that you're using a debug build of bjam. Maybe we should change things so people get a release build? could speed up testing)
Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
At Monday 2004-09-27 22:16, you wrote:
At Monday 2004-09-27 05:19, you wrote:
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
I've had to remove mingw from my regression testing since it's creating .lib files which cause bjam to "except" when running the tests. I can see _what_ the problem is, but not _why_ it is. Here's the call stack (well what appears relevant... the top when the error occurs) [deleted]
http://tinyurl.com/5vwpf seems to indicate that we can fix it by changing
if( !isspace(*endname) && *endname != '\\' && *endname != '/' )
to
if( (unsigned)(c + 1) > 256 || !isspace(*endname) && *endname != '\\' && *endname != '/' )
nope, nor does: if( (unsigned)(*endname + 1) > 256 || !isspace(*endname) && *endname != '\\' && *endname != '/' )
the problem just gets postponed and eventually someone tries to access 0xfdfdfdfd
however, changing the malloc back several lines to be one larger, then putting a '\0' at the end _does_ seem to fix it.
Checked into CVS.
in tools/build/jam_src/filent.c
Could you try making that change and letting us know how it works out?
(BTW, this also indicates that you're using a debug build of bjam. Maybe we should change things so people get a release build? could speed up testing)
oh yeah, I manually built a debug version in order to find this problem, the script normally builds a release version, then uses it.
Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
nope, nor does: if( (unsigned)(*endname + 1) > 256 || !isspace(*endname) && *endname != '\\' && *endname != '/' )
the problem just gets postponed and eventually someone tries to access 0xfdfdfdfd
however, changing the malloc back several lines to be one larger, then putting a '\0' at the end _does_ seem to fix it.
Checked into CVS.
Thanks! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (3)
-
David Abrahams -
Stefan Slapeta -
Victor A. Wagner Jr.