Bug 1803, Upcoming breaking changes for 4.10.0-beta1
Tamas Szekeres
szekerest at GMAIL.COM
Mon Aug 21 08:05:31 EDT 2006
Here is the code sample to demonstrate the error exclusively for this
issue (the code fragment was extracted from the sample mentioned
previously):
import edu.umn.gis.mapscript.*;
public class DrawMap {
public static void main(String[] args) {
try
{
System.loadLibrary("mapscript");
}
catch(UnsatisfiedLinkError ule)
{
System.err.println(ule);
System.exit(-1);
}
mapObj map = new mapObj(args[0]);
//<usafe code> (causes access violation)
webObj web = new webObj();
web.setImagepath("/tmp/");
web.setImageurl("http://katrin/~nicol/mapserver/tmp/");
web.setLog("/tmp/wms.log");
web.setHeader("nh_header.html");
web.setTemplate("../html/form.html");
web.setEmpty("../themen/noFeature.html");
web.setMap(map);
map.setWeb(web);
//</unsafe code>
//<safe code>
// webObj web = map.getWeb();
// web.setImagepath("/tmp/");
// web.setImageurl("http://katrin/~nicol/mapserver/tmp/");
// web.setLog("/tmp/wms.log");
// web.setHeader("nh_header.html");
// web.setTemplate("../html/form.html");
// web.setEmpty("../themen/noFeature.html");
//</safe code>
map.delete();
web.delete();
}
}
After running this program I got:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c910f29, pid=6064, tid=3820
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_07-b03 mixed mode, sharing)
# Problematic frame:
# C [ntdll.dll+0x10f29]
#
--------------- T H R E A D ---------------
Current thread (0x000376a8): JavaThread "main" [_thread_in_native, id=3820]
siginfo: ExceptionCode=0xc0000005, reading address 0x6e7e2f6e
Registers:
EAX=0x03b97c70, EBX=0x03870000, ECX=0x6e7e2f6e, EDX=0x69727461
ESP=0x0007d8f4, EBP=0x0007d900, ESI=0x03b97c68, EDI=0x03b97c20
EIP=0x7c910f29, EFLAGS=0x00010283
Top of Stack: (sp=0x0007d8f4)
0x0007d8f4: 03870000 03b97c38 00000000 0007d9d4
0x0007d904: 7c910d5c 03b97c68 6e7e2f6e 0007d9b8
0x0007d914: 00000000 7c342151 03b97c40 26aefcf8
0x0007d924: 00000000 00000002 03b97bb0 03afb388
0x0007d934: 7ffdf000 03b5f000 7ffdf000 03b97bb8
0x0007d944: 00000040 03870330 03870240 03870228
0x0007d954: 00000058 03870218 00000468 00000010
0x0007d964: 00000000 03870000 03870218 00019648
Instructions: (pc=0x7c910f29)
0x7c910f19: 85 92 00 00 00 8b 4e 0c 8d 46 08 8b 10 89 4d 0c
0x7c910f29: 8b 09 3b 4a 04 89 55 14 0f 85 ea 0f 00 00 3b c8
Stack: [0x00040000,0x00080000), sp=0x0007d8f4, free space=246k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [ntdll.dll+0x10f29]
C [ntdll.dll+0x10d5c]
C [MSVCR71.dll+0x218a]
C [libmap.dll+0x1e5a1]
C [mapscript.dll+0xa483]
j edu.umn.gis.mapscript.mapscriptJNI.delete_webObj(J)V+0
j edu.umn.gis.mapscript.webObj.delete()V+25
j DrawMap.main([Ljava/lang/String;)V+90
v ~StubRoutines::call_stub
V [jvm.dll+0x86401]
V [jvm.dll+0xdb172]
V [jvm.dll+0x862d2]
V [jvm.dll+0x8d2a2]
C [java.exe+0x14c5]
C [java.exe+0x69cd]
C [kernel32.dll+0x16d4f]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j edu.umn.gis.mapscript.mapscriptJNI.delete_webObj(J)V+0
j edu.umn.gis.mapscript.webObj.delete()V+25
j DrawMap.main([Ljava/lang/String;)V+90
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00a70430 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=4932]
0x00a6eec0 JavaThread "CompilerThread0" daemon [_thread_blocked, id=5772]
0x00a6e150 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=416]
0x00a39ea8 JavaThread "Finalizer" daemon [_thread_blocked, id=1100]
0x00a48aa0 JavaThread "Reference Handler" daemon [_thread_blocked, id=5188]
=>0x000376a8 JavaThread "main" [_thread_in_native, id=3820]
Other Threads:
0x00a68470 VMThread [id=5304]
0x00a71680 WatcherThread [id=5496]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 576K, used 287K [0x22ad0000, 0x22b70000, 0x22fb0000)
eden space 512K, 56% used [0x22ad0000, 0x22b17ff0, 0x22b50000)
from space 64K, 0% used [0x22b50000, 0x22b50000, 0x22b60000)
to space 64K, 0% used [0x22b60000, 0x22b60000, 0x22b70000)
tenured generation total 1408K, used 0K [0x22fb0000, 0x23110000, 0x26ad0000)
the space 1408K, 0% used [0x22fb0000, 0x22fb0000, 0x22fb0200, 0x23110000)
compacting perm gen total 8192K, used 239K [0x26ad0000, 0x272d0000,
0x2aad0000)
the space 8192K, 2% used [0x26ad0000, 0x26b0bd50, 0x26b0be00, 0x272d0000)
ro space 8192K, 67% used [0x2aad0000, 0x2b02d9f8, 0x2b02da00, 0x2b2d0000)
rw space 12288K, 46% used [0x2b2d0000, 0x2b873808, 0x2b873a00, 0x2bed0000)
Dynamic libraries:
0x00400000 - 0x0040d000 C:\Progra~1\Java\jdk1.5.0_07\bin\java.exe
0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll
0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll
0x77c10000 - 0x77c68000 C:\WINDOWS\system32\MSVCRT.dll
0x6d730000 - 0x6d8c7000 C:\Progra~1\Java\jdk1.5.0_07\jre\bin\client\jvm.dll
0x77d40000 - 0x77dd0000 C:\WINDOWS\system32\USER32.dll
0x77f10000 - 0x77f56000 C:\WINDOWS\system32\GDI32.dll
0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll
0x6d2f0000 - 0x6d2f8000 C:\Progra~1\Java\jdk1.5.0_07\jre\bin\hpi.dll
0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL
0x6d700000 - 0x6d70c000 C:\Progra~1\Java\jdk1.5.0_07\jre\bin\verify.dll
0x6d370000 - 0x6d38d000 C:\Progra~1\Java\jdk1.5.0_07\jre\bin\java.dll
0x6d720000 - 0x6d72f000 C:\Progra~1\Java\jdk1.5.0_07\jre\bin\zip.dll
0x10000000 - 0x10072000 C:\cvs\buildkit\mapserver0\mapscript\java\mapscript.dll
0x02ca0000 - 0x02d5d000 C:\cvs\buildkit\bin\bgd.dll
0x61b80000 - 0x61b97000 C:\Program Files\Mono-1.1.13.2\bin\zlib1.dll
0x7c340000 - 0x7c396000 C:\WINDOWS\system32\MSVCR71.dll
0x02d60000 - 0x02e78000 C:\cvs\buildkit\bin\libmap.dll
0x02e80000 - 0x02eb6000 C:\cvs\buildkit\bin\proj.dll
0x02ec0000 - 0x033f7000 C:\cvs\buildkit\bin\gdal13.dll
0x12000000 - 0x121ad000 C:\cvs\buildkit\bin\xerces-c_2_7.dll
0x71ab0000 - 0x71ac7000 C:\WINDOWS\system32\WS2_32.dll
0x71aa0000 - 0x71aa8000 C:\WINDOWS\system32\WS2HELP.dll
0x63100000 - 0x63121000 C:\WINDOWS\system32\LIBPQ.dll
0x03400000 - 0x034d1000 C:\WINDOWS\system32\libeay32.dll
0x71ad0000 - 0x71ad9000 C:\WINDOWS\system32\WSOCK32.dll
0x034e0000 - 0x034ed000 C:\WINDOWS\system32\libintl-2.dll
0x034f0000 - 0x035cb000 C:\WINDOWS\system32\libiconv-2.dll
0x76780000 - 0x76789000 C:\WINDOWS\system32\SHFOLDER.DLL
0x035d0000 - 0x035f7000 C:\WINDOWS\system32\ssleay32.dll
0x74320000 - 0x7435d000 C:\WINDOWS\system32\ODBC32.dll
0x5d090000 - 0x5d127000 C:\WINDOWS\system32\COMCTL32.dll
0x7c9c0000 - 0x7d1d4000 C:\WINDOWS\system32\SHELL32.dll
0x77f60000 - 0x77fd6000 C:\WINDOWS\system32\SHLWAPI.dll
0x763b0000 - 0x763f9000 C:\WINDOWS\system32\comdlg32.dll
0x39d00000 - 0x39e19000 C:\cvs\buildkit\bin\libecwj2.dll
0x76c90000 - 0x76cb8000 C:\WINDOWS\system32\imagehlp.dll
0x77c00000 - 0x77c08000 C:\WINDOWS\system32\VERSION.dll
0x77a80000 - 0x77b14000 C:\WINDOWS\system32\CRYPT32.dll
0x77b20000 - 0x77b32000 C:\WINDOWS\system32\MSASN1.dll
0x774e0000 - 0x7761c000 C:\WINDOWS\system32\ole32.dll
0x7c3a0000 - 0x7c41b000 C:\WINDOWS\system32\MSVCP71.dll
0x03600000 - 0x03620000 C:\cvs\buildkit\bin\geotiff.dll
0x03620000 - 0x036b8000 C:\cvs\buildkit\bin\libtiff.dll
0x036c0000 - 0x03801000 C:\cvs\buildkit\bin\LIBMYSQL.dll
0x77120000 - 0x771ac000 C:\WINDOWS\system32\OLEAUT32.dll
0x03810000 - 0x0384e000 C:\cvs\buildkit\bin\libcurl.dll
0x773d0000 - 0x774d2000
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll
0x20000000 - 0x20017000 C:\WINDOWS\system32\odbcint.dll
0x77690000 - 0x776b1000 C:\WINDOWS\system32\NTMARTA.DLL
0x76f60000 - 0x76f8c000 C:\WINDOWS\system32\WLDAP32.dll
0x71bf0000 - 0x71c03000 C:\WINDOWS\system32\SAMLIB.dll
VM Arguments:
jvm_args: -Djava.library.path=.
java_command: DrawMap ..\..\tests\test.map .\map.png
Launcher Type: SUN_STANDARD
Environment Variables:
CLASSPATH=.;C:\Program Files\Java\jre1.5.0_01\lib\ext\QTJava.zip
PATH=C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\IDE;C:\Program Files\Microsoft Visual Studio .NET
2003\VC7\BIN;C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\Tools\bin\prerelease;C:\Program Files\Microsoft Visual
Studio .NET 2003\Common7\Tools\bin;C:\Program Files\Microsoft Visual
Studio .NET 2003\SDK\v1.1\bin;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;c:\MinGW\bin;C:\Perl\bin\;C:\mingw\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Microsoft SQL Server\80\Tools\BINN;C:\Program Files\Microsoft
SQL Server\80\Tools\Binn\;C:\PostgreSQLWin32\bin;C:\Program
Files\Common Files\Ulead Systems\MPEG;c:\Program Files\Microsoft SQL
Server\90\Tools\binn\;C:\Program Files\GnuWin32\bin;C:\Program
Files\Mono-1.1.13.2\bin;C:\cvs\buildkit\bin;C:\Program
Files\QuickTime\QTSystem\;C:\Program
Files\Java\jdk1.5.0_07\bin;C:\Program Files\Microsoft Visual
Studio\Common\Tools\WinNT;C:\Program Files\Microsoft Visual
Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual
Studio\Common\Tools;C:\Program Files\Microsoft Visual
Studio\VC98\bin;C:\Program Files\GnuWin32\bin;C:\Program
Files\Mono-1.1.13.2\bin;C:\cvs\buildkit\bin;C:\Program
Files\Java\jdk1.5.0_07\bin;
USERNAME=Szekeres Tamás
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 7, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows XP Build 2600 Service Pack 2
CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
Memory: 4k page, physical 1047992k(381540k free), swap 1733624k(1195208k free)
vm_info: Java HotSpot(TM) Client VM (1.5.0_07-b03) for windows-x86,
built on May 3 2006 01:04:38 by "java_re" with MS VC++ 6.0
If you replace the *erroneous* code with the safe one the program runs
correctly.
Once again, i would not be willing to make demonstrations for all of
the concerning members since this problem need not to be identifyed
further. One can see the issue by looking into the SWIG generated
code.
Tamas
2006/8/21, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> Hi all,
> got back today and I have already a bug report because of the changes
> approved in this thread: an API change in 4.10 and probably another in
> 5 is not too respectful of our users I guess.
>
> Now since the majority of the devs has voted in favour of the proposal
> and I do not have veto rights I'll go on and downgrade the Java
> examples to the newer functionality, but needless to say I'm *very
> disappointed* and I'll consider proposing to make some of these
> changes c-sharp specific since the fatal errors that Tamas seems to
> experience in c-sharp I cannot reproduce them in Java.
>
> Umberto
>
> On 8/18/06, Tamas Szekeres <szekerest at gmail.com> wrote:
> > Along with Frank's +1 on the IRC we have at least +3 so i have
> > committed the changes.
> > HISTORY.TXT contains the interface elements affected.
> >
> > /me thinks it was a bit sweaty but was worth the trouble
> >
> > Tamas
> >
> >
> > 2006/8/17, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> > > +1 from me too. The nice thing it's a beta release so there's still time
> > > if we
> > > find we've overstepped a boundary. This is good discussion and I want
> > > to
> > > thank Tamas for the investigative work and solution (and Umberto for
> > > taking
> > > time from vacation - you're more generous than I!)...
> > >
> > > Steve
> > >
> > > >>> Daniel Morissette <dmorissette at MAPGEARS.COM> 8/17/2006 4:03:53 PM
> > > >>>
> > > After a bit more thinking and discussion on IRC, I am with Steve and
> > > also think that all the members that are listed in Steve's email can
> > > safely be made immutable since it would not make sense to attempt to
> > > overwrite them anyway. (That's also the way things are in PHP MapScript
> > >
> > > and that never stopped us from doing anything).
> > >
> > > With respect to imageObj.format, I think it should be made read-only or
> > >
> > > hidden since we get an imageObj from methods that create the actual
> > > image, and changing the outputFormatObj on the image after it's been
> > > created is just asking for trouble (not to mention the possible object
> > >
> > > referencing issues that Tamas is trying to address).
> > >
> > > I give my +1 to go ahead with this.
> > >
> > > Also please make sure you include a note listing the members that were
> > >
> > > made immutable in HISTORY.TXT.
> > >
> > > Daniel
> > >
> > > Steve Lime wrote:
> > > > Umberto: How do you add classes and layers at runtime? In the context
> > > of
> > > > a layer or a map
> > > > correct? I don't believe that what Tamas is proposing would change
> > > that
> > > > capability at all.
> > > >
> > > > If you look at the list:
> > > >
> > > > classObj.layer
> > > > webObj.map
> > > > legendObj.map
> > > > layerObj.map
> > > >
> > > > are back references and you don't want folks monkeying around with
> > > > them.
> > > >
> > > > classObj.label
> > > > legendObj.label
> > > > mapObj.scalebar
> > > > mapObj.legend
> > > > mapObj.querymap
> > > > mapObj.web
> > > > mapObj.symbolset
> > > > mapObj.labelcache
> > > > mapObj.reference
> > > >
> > > > Already exist in their parent objects so there is no need to create
> > > new
> > > > ones in place of the
> > > > existing ones. Users should get the reference to the existing
> > > structure
> > > > and modify it in place.
> > > > I'm not sure that given the potential problems that it even makes
> > > sense
> > > > to have constructors
> > > > for these. I assume this is the contentious spot...
> > > >
> > > > (If there is a glaring need to have, for example, an unattached
> > > > labelObj laying around then
> > > > couldn't a populateFrom capability be developed for a labelObj, or
> > > > perhaps setLabel() for a
> > > > classObj?)
> > > >
> > > > classObj.metadata
> > > > fontSetObj.fonts
> > > > mapObj.configoptions
> > > > webObj.metadata
> > > >
> > > > Are hash tables and Sean created a nice interface for them to use.
> > > > Modifying directly shouldn't
> > > > be allowed. I think this is what was ok'd yesterday.
> > > >
> > > > Note sure about imageObj.format...
> > > >
> > > > I guess I don't see the big deal with this change. My 2 cents.
> > > >
> > > > Steve
> > > >
> > > >
> > > >>>>Umberto Nicoletti <umberto.nicoletti at GMAIL.COM> 8/17/2006 8:25 AM
> > > >>>>
> > > >
> > > > On 8/17/06, Daniel Morissette <dmorissette at mapgears.com> wrote:
> > > >
> > > >>Tamas Szekeres wrote:
> > > >>
> > > >>>>I think you can safely hide the labelPathObj, that should not be
> > > >>>>exposed. I think the others
> > > >>>>should be immutable too (assuming I understand the problem
> > > >
> > > > correctly),
> > > >
> > > >>>>the question is how
> > > >>>>many scripts will the change break and should backward
> > > >
> > > > compatability
> > > >
> > > >>>>breakage be limited
> > > >>>>to major releases (e.g. 5.0).
> > > >>>>
> > > >>>
> > > >>>Those scripts are *erroneous* ! It would be desirable to force
> > > >
> > > > the
> > > >
> > > >>>users to put them into a good shape as soon as possible.
> > > >>>
> > > >>>
> > > >>
> > > >>It seems that I should take position as release manager but
> > > >>unfortunately I do not know or use SWIG MapScript much so I have to
> > > >
> > > > rely
> > > >
> > > >>on those who know to make an opinion on whether the current stuff is
> > > >>dangerous enough to warrant breaking a few scripts with 4.10.
> > > >>
> > > >>Based on the understanding I have of the problem from reading this
> > > >>thread and previous discussions, it seems to me that if those
> > > >
> > > > scripts
> > > >
> > > >>are doing something that is just waiting to bomb then changing SWIG
> > > >>MapScript in v4.10 to make those object references immutable is not
> > > >
> > > > a
> > > >
> > > >>backwards compatibility issue, it is a bugfix and a service we are
> > > >>making to those users by forcing them to fix their scripts... and in
> > > >
> > > > the
> > > >
> > > >>end their apps will just be more robust.
> > > >>
> > > >
> > > >
> > > > Daniel,
> > > > IMO we are talking about fixing pieces of code we are not even sure
> > > > they are broken. For instance I have some Java mapscript tests (and
> > > an
> > > > application) running just fine that add layers and classes at run
> > > time
> > > > and that's why I am so reluctant in approving this proposal. Only
> > > once
> > > > we get a test case that reproduces this errors reliably then we can
> > > go
> > > > and change the code.
> > > >
> > > > Unfortunately I couldn't join the IRC meeting because I am on
> > > vacation
> > > > otherwise I'd have spoken earlier (I am writing this on the road).
> > > >
> > > > Regards,
> > > > Umberto
> > > >
> > > >
> > > >>The real question that I would throw at the SWIG MapScript experts
> > > >
> > > > is:
> > > >
> > > >>"Is the practice of overwriting those object references really
> > > >
> > > > dangerous
> > > >
> > > >>or not?"
> > > >>
> > > >>If the answer is yes then I think that solves the question and we
> > > >
> > > > need
> > > >
> > > >>to apply the fix and force users to fix their scripts.
> > > >>
> > > >>If there are object references that can safely be overwritten (such
> > > >
> > > > as
> > > >
> > > >>colorObj) then my opinion is that we should not touch them in 4.10.
> > > >>
> > > >>Daniel
> > > >>--
> > > >>Daniel Morissette
> > > >>http://www.mapgears.com/
> > > >>
> > > >
> > > >
> > >
> > >
> > > --
> > > Daniel Morissette
> > > http://www.mapgears.com/
> > >
> >
>
More information about the mapserver-dev
mailing list