View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000687||Subversion for OS/2 & eCS||Bug||public||2019-04-08 11:37||2019-04-24 19:19|
|Reporter||Steven Levine||Assigned To||psmedley|
|Platform||OS2/eCS||OS||OS/2 or eComstation||OS Version||1.x 2.x or 4.5|
|Summary||0000687: svn, version 1.7.21 (r1692801) traps for svn diff deleted-file|
|Description|| svn deleted-file|
traps after svn rm deleted-files
|Steps To Reproduce||Create a test file (deleted-file)|
Commit to repo
svn rm deleted-file
svn diff deleted-file
|Additional Information||The trap occurs because some errant code corrupts the apr_file_t theFile so that the buffered flag is non-zero, but the buffer pointer is null, as it should be. The causes the memcpy() called by apr_file_write() to trap.|
The errant code may be in svn_io_open_unique_file3(). but this has not been completely confirmed.
The debugger indicates that the wildcard pattern d:\sla_dev2\testsvn\* is overwriting the theFile at theFile->timeout. This is an odd location for the overwrite to start, so it is possible that there is structure size mismatch somewhere.
00DF_01.TRP-shl is an annotated .trp file which contains the analysis results to date.
Paul, please provide an svn.exe build with debug symbols when it is convenient.
|Tags||No tags attached.|
00DF_01.TRP-shl (35,286 bytes)
||debug build = http://smedley.id.au/tmp/svn-debug-20190409.zip - I haven't had time to look at the annotated trp file yet|
Thanks for the quick debug build, but it was not sufficiently complete. The following files were missing debug data:
idebug is hard to work with when there are missing symbols. wdw is much better at displaying code at arbitrary addresses.
Back to our issue...
There seems to be a problem with the source code or the code generation for apr_file_open().
Based on my reference sources, we should have:
dafile->buffered = (flag & APR_FOPEN_BUFFERED) > 0;
However, this in not in the compiled binary. The result is that dafile->buffered is uninitialized and the previous value which happens to be non-zero is used and this causes the trap in apr_file_write->memcpy because the buffer parameter is NULL, as it should be.
The memory happened to be previously used by apr_dir_open which is where the 0x2a comes from.
I have refreshed 00DF_01.TRP-shl with some additional data dumped from pmdf which shows the memory content a bit more clearly.
00DF_01-2.TRP-shl (36,282 bytes)
OK - looks like I mangled open.c trying to fix another issue.
No idea why debug is missing from readwrite.c - it's built using:
gcc -D__EMX__ -DOS2 -Zomf -DTCPV40HDRS -D__ST_MT_ERRNO__ -g -static-libgcc -DHAVE_CONFIG_H -DOS2 -I./include -IU:/DEV/apr-1.6.5/include/arch/os2 -I./include/arch/unix -IU:/DEV/apr-1.6.5/include/arch/unix -IU:/DEV/apr-1.6.5/include -IU:/DEV/apr-1.6.5/include/private -IU:/DEV/apr-1.6.5/include/private -o file_io/os2/readwrite.o -c file_io/os2/readwrite.c -Zomf
similarly for main.c:
ash.exe U:/DEV/subversion-1.7.21/libtool --tag=CC --silent --mode=compile gcc -DOS2 -D__EMX__ -DOS2 -Zomf -DTCPV40HDRS -D__ST_MT_ERRNO__ -g -static-libgcc -Zmt -Werror=implicit-function-declaration -I./subversion/include -I./subversion -I/extras/include/apr-1 -I/extras/include/apr-1 -I/extras/include/neon -I/extras/include/serf-1 -static -o subversion/svn/main.lo -c subversion/svn/main.c
Anyhow, updated debug build at http://smedley.id.au/tmp/svn-debug-20190410.zip
This build resolves the trap. Thanks.
It's not so much that debug builds have stopped working, but that the IBM debuggers are now behaving differently and it's hard to know why this change occurred.
In the past, when I started up the debugger, the app would stop at main and the console would show all the source files with debug data. Now, the app runs to completion unless I prevent the debugger from running the runtime initialization code. If I do this, I can set breakpoints as before.
Not all source files with debug data are showing in the console. For example, dir.c does not show up in the list, but I can use File->Open source and set the breakpoints as expected.
However, I can work around these issues, so this is not that we need to address right now.
When you get a chance, please generate a diff of the current subversion and apr patch so that I can bring my local git repo into sync.
http://smedley.id.au/tmp/subversion-1.7.21-os2-20190420.zip has a release build
Diffs are at:
||I think we can mark this ticket resolved.|
|2019-04-08 11:37||Steven Levine||New Issue|
|2019-04-08 11:37||Steven Levine||File Added: 00DF_01.TRP-shl|
|2019-04-09 19:26||psmedley||Note Added: 0003282|
|2019-04-10 04:34||Steven Levine||File Added: 00DF_01-2.TRP-shl|
|2019-04-10 04:34||Steven Levine||Note Added: 0003283|
|2019-04-10 18:47||psmedley||Note Added: 0003284|
|2019-04-11 06:01||Steven Levine||Note Added: 0003285|
|2019-04-20 18:56||psmedley||Note Added: 0003286|
|2019-04-24 03:46||Steven Levine||Note Added: 0003288|
|2019-04-24 19:19||psmedley||Assigned To||=> psmedley|
|2019-04-24 19:19||psmedley||Status||new => resolved|
|2019-04-24 19:19||psmedley||Resolution||open => fixed|