SmartSVN fails with EXCEPTION_ACCESS_VIOLATION

[rbri]

SmartSVN 6.6.3 fails at startup after showing the splashscreen but before the GUI is visible.

This was tested with beta2 (and the SMP Kernel)

[rbri]

Error dump from the JVM

[dmik]

Do you mean that they re-enabled OpenJDK 6 support in SmartSVN?

[dmik]

And keep in mind that SMP is *not* currently supported (this is mentioned in README.OS2).

[dmik]

Aha, they have added the smartsvn.checkIncompatibleJava property that, being set to false, allows it to run under OpenJDK 6. Great!

And 6.6.3 with -Dsmartsvn.checkIncompatibleJava=false and OpenJDK Beta 2 actually kind of works here.

One thing that doesn't is requesting the license though. It gives me the following:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x1cf00d7a, pid=86, tid=5636114
#
# JRE version: 6.0
# Java VM: OpenJDK Client VM (16.0-b13 mixed mode os2-x86 )
# Problematic frame:
# C  [IPHLPAPI+0xd7a]
#
# An error report file with more information is saved as:
# D:\Apps\Java\smartsvn-6_6_3\lib\hs_err_pid86.log
SYS1808:
The process has stopped.  The software diagnostic
code (exception code) is  0005.


01-13-2011  00:22:17  SYS3175  PID 0056  TID 0012  Slot 009d
D:\DEV\OPENJDK6_B19_SDK_OS2_BETA2-20110112\JRE\BIN\JAVA.EXE
c0000005
1cf00d7a
P1=00000000  P2=ffffffff  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=fee8858b  EBX=044df9a4  ECX=044df9e0  EDX=044df9c8
ESI=00000000  EDI=2114c5c0  
DS=0053  DSACC=d0f3  DSLIM=5fffffff  
ES=0053  ESACC=d0f3  ESLIM=5fffffff  
FS=20cf  FSACC=00f3  FSLIM=00000fff
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1d56d448  CSACC=d0df  CSLIM=5fffffff
SS:ESP=0053:044df944  SSACC=d0f3  SSLIM=5fffffff
EBP=044df96c  FLG=00010246

IPHLPAPI.DLL 0001:00000d7a

The HS log is attached below.

Please try to switch to UNI and also start it several times. Does it always crash? And at what point, exactly?

[BlondeGuy]

I am seeing this if I use SMP.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x1cbbabd8, pid=170, tid=111411
40
#
# JRE version: 6.0
# Java VM: OpenJDK Client VM (16.0-b13 mixed mode os2-x86 )
# Problematic frame:
# V  [JVM+0x39abd8]
#
# An error report file with more information is saved as:
# D:\suntanv6\pending\smartsvn\smartsvn-6_6_3\bin\hs_err_pid170.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

I get a different crash with the W4 kernel on an older machine. I'll try to attach bug-20110116064103.zip below.

[BlondeGuy]

Dump from running SmartSVN on W4 kernel

[dmik]

The crash in IPHLPAPI has been fixed in Odin r 21563. The crash happened not on all systems, for example on my eCS/VBox it worked, while on a Thinkpad it crashed. On VBox I have an AMD PCNet NIC card and an old IBM driver for it while the Thinkpad uses the newest driver for the Intel Gigabit NIC from the Ukrainian guys. BlondeGuy, it seems that you didn't experience this crash; out of curiosity, what NIC and driver do you have?

Now SmartSVN can successfully download the evaluation license. The next problem here is this (exactly as in your last zip, thanks for the info):

Exception in thread "main" java.nio.channels.OverlappingFileLockException
        at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(FileChannelImpl.java:1215)
        at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(FileChannelImpl.java:1117)
        at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:923)
        at java.nio.channels.FileChannel.tryLock(FileChannel.java:978)
        at smartsvn.aLq.a(SourceFile:29)
        at smartsvn.aLt.<init>(SourceFile:121)
        at smartsvn.aLt.a(SourceFile:62)
        at smartsvn.aLy.a(SourceFile:165)
        at smartsvn.aLy.<init>(SourceFile:40)
        at smartsvn.asY.c(SourceFile:178)
        at smartsvn.asY.a(SourceFile:65)
        at smartsvn.PR.a(SourceFile:691)
        at smartsvn.PR.a(SourceFile:226)
        at SmartSVN.main(SourceFile:11)

[dmik]

Found a problem. It's the GetFileInformationByHandle() call. Java uses the nFileIndexLow, nFileIndexHigh and dwVolumeSerialNumber fields of the BY_HANDLE_FILE_INFORMATION structure to comprise a unique file hash. These values are currently always 0 in Odin which means the hash is the same for all files... Since this hash is used as a key in the table of locks, it makes FileChannelImpl think the file lock is already held while it actually belongs to two different files (but with the same hash value).

I need to find a way to emulate these index fields (the volume serial number field I will obtain from DosQueryFSInfo()).

[dmik]

Fixed GetFileInformationByHandle() in Odin (r 21564).

Now I get further with SmartSVN and get the following from it:

Exception in thread "main" smartsvn.bg: java.lang.InternalError: Can't instantiate platform default Preferences factory java.util.prefs.FileSystemPreferencesFactory
        at smartsvn.qy.c(SourceFile:93)
        at smartsvn.qy.a(SourceFile:41)
        at smartsvn.QA.a(SourceFile:59)
        at smartsvn.PR.a(SourceFile:278)
        at SmartSVN.main(SourceFile:11)
Caused by: java.lang.InternalError: Can't instantiate platform default Preferences factory java.util.prefs.FileSystemPreferencesFactory
        at java.util.prefs.Preferences.factory1(Preferences.java:301)
        at java.util.prefs.Preferences.access$000(Preferences.java:225)
        at java.util.prefs.Preferences$2.run(Preferences.java:272)
        at java.util.prefs.Preferences$2.run(Preferences.java:270)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.util.prefs.Preferences.factory(Preferences.java:269)
        at java.util.prefs.Preferences.<clinit>(Preferences.java:227)
        at com.jidesoft.swing.AbstractLayoutPersistence.loadLayoutDataFrom(AbstractLayoutPersistence.java:352)
        at com.jidesoft.swing.AbstractLayoutPersistence.loadLayoutData(AbstractLayoutPersistence.java:223)
        at smartsvn.zU.b(SourceFile:188)
        at smartsvn.Qj.<init>(SourceFile:231)
        at smartsvn.Qj.a(SourceFile:77)
        at smartsvn.PM.a(SourceFile:412)
        at smartsvn.QB.run(SourceFile:69)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:216)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
Caused by: java.lang.ClassNotFoundException: java/util/prefs/FileSystemPreferencesFactory
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:264)
        at java.util.prefs.Preferences.factory1(Preferences.java:298)
        ... 21 more

[dmik]

After r244, SmartSVN launched and even works (in UNI mode)! I actually made this commit right from there :)

[dmik]

I noticed two glitches so far: it doesn't want to save the maximized state (does not restore it at restart) and it gives 99% CPU load at startup. Other than that it seems to work well.

[dmik]

Turns out that the CPU load is due to the recursion in the paint event: when the modal window (e.g. a dialog showing recent working copies) is in focus, Swing keeps continuously redrawing the pressed tool button at a high rate. Probably, due to different event scheduling in OS/2, some other messages can't get processed in between and hence the recursion. Bad that we don't have SmartSVN sources.

[dmik]

It turned out to be SmartSVN bug which is fixed in 6.6.4, ​http://www.syntevo.com/smartsvn/changelog.txt:

- Various dialogs: For "Metal L&F", if a dialog is shown, the CPU
  is at ~50%

Apparently, this not only relates to Metal L&F but also to the SmartSVN's own L&F, at least under OpenJDK6.

Just in time. But I learned a lot on how to debug such complex cases now.