[jira] [Closed] (LANG-785) trim(String source, String trimString)
[
https://issues.apache.org/jira/browse/LANG-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible closed LANG-785.
---
Resolution: Not A Problem
Assignee: Joerg Schaible
Lang contains trim functionality in several flavors for ages. Howerver, please,
if you have question, ask on the user's list. JIRA is a bug tracker and no help
forum.
> trim(String source, String trimString)
> --
>
> Key: LANG-785
> URL: https://issues.apache.org/jira/browse/LANG-785
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Alexey Kuznetsov
>Assignee: Joerg Schaible
>Priority: Minor
>
> I'm looking for simple function called trim in many langues.
> Simple function like this:
> public String trim(String source, String trimString) {
> source = StringUtils.removeStart(source, trimString);
> source = StringUtils.removeEnd(source, trimString);
> return source;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-301) commons-io: IOUtils.closeQuietly(Selector) necessary
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189651#comment-13189651 ] Karthik K commented on IO-301: -- IOUtils.closeQuietly(Selector) has some test cases as well. > commons-io: IOUtils.closeQuietly(Selector) necessary > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-301) commons-io: IOUtils.closeQuietly(Selector) necessary
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik K updated IO-301: - Attachment: IO-301.patch > commons-io: IOUtils.closeQuietly(Selector) necessary > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-301) commons-io: IOUtils.closeQuietly(Selector) necessary
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik K updated IO-301: - Attachment: (was: IO-301.patch) > commons-io: IOUtils.closeQuietly(Selector) necessary > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-301) commons-io: IOUtils.closeQuietly(Selector) necessary
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik K updated IO-301: - Attachment: IO-301.patch > commons-io: IOUtils.closeQuietly(Selector) necessary > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > Attachments: IO-301.patch > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-301) commons-io: IOUtils.closeQuietly(Selector) necessary
[ https://issues.apache.org/jira/browse/IO-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik K updated IO-301: - Description: IOUtils.closeQuietly(Selector) would be useful to fix yet another resource leakage. (was: IOUtils.closeQuietly(Selector) added in place. ) Summary: commons-io: IOUtils.closeQuietly(Selector) necessary (was: commons-io: IOUtils.closeQuietly(Selector) added ) > commons-io: IOUtils.closeQuietly(Selector) necessary > -- > > Key: IO-301 > URL: https://issues.apache.org/jira/browse/IO-301 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.1 >Reporter: Karthik K > Fix For: 2.2 > > > IOUtils.closeQuietly(Selector) would be useful to fix yet another resource > leakage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-301) commons-io: IOUtils.closeQuietly(Selector) added
commons-io: IOUtils.closeQuietly(Selector) added -- Key: IO-301 URL: https://issues.apache.org/jira/browse/IO-301 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.1 Reporter: Karthik K Fix For: 2.2 IOUtils.closeQuietly(Selector) added in place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-785) trim(String source, String trimString)
trim(String source, String trimString)
--
Key: LANG-785
URL: https://issues.apache.org/jira/browse/LANG-785
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Reporter: Alexey Kuznetsov
Priority: Minor
I'm looking for simple function called trim in many langues.
Simple function like this:
public String trim(String source, String trimString) {
source = StringUtils.removeStart(source, trimString);
source = StringUtils.removeEnd(source, trimString);
return source;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-358) Early return/termination for graph visit
Early return/termination for graph visit
Key: SANDBOX-358
URL: https://issues.apache.org/jira/browse/SANDBOX-358
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Claudio Squarcella
Priority: Minor
Hello,
the current implementations in the class {{Visit}} (package
{{org.apache.commons.graph.visit}}) do not include the possibility to stop the
search prematurely. That would be more natural (and faster) for many kinds of
search, e.g. when looking for the first occurrence of a specific pattern
(vertex, path with certain features, etc).
The easiest solution: changing all method signatures in {{GraphVisitHandler}}
from {{void}} to {{boolean}}, forcing the handler to answer the question:
_should I continue?_
I understand semantics get a bit entangled (well, not with an appropriate
documentation!), so I am open to more verbose options: e.g. a method
{{isSearchComplete}} to call after every step... but that would only be more
verbose, wouldn't it?
Waiting for feedback and ready to patch :-)
Claudio
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Honton updated LANG-462: Attachment: with_interfaces2.patch Trial & error (mostly error) to get a diff that will work. This patch works against trunk with no other patches. > FastDateFormat supports parse > - > > Key: LANG-462 > URL: https://issues.apache.org/jira/browse/LANG-462 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Franz Wong > Fix For: 3.x > > Attachments: DateParser.patch, LANG-462-FormatCache.patch, > LANG-462-Hen.patch, UseFormatCache.patch, lang462.patch, > with_interfaces.patch, with_interfaces2.patch, with_updated_tests.patch > > > Currently FastDateFormat only supports formatting the ISO8601 time zone, > however, it doesn't support parsing such string to Date. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-300) FileUtils.moveDirectoryToDirectory removing source directory
FileUtils.moveDirectoryToDirectory removing source directory
Key: IO-300
URL: https://issues.apache.org/jira/browse/IO-300
Project: Commons IO
Issue Type: Bug
Reporter: dennis lucero
Since moveDirectoryToDirectory performs a copy then delete, if you specify a
target directory that is a subdirectory of the source, everything under the
source directory is deleted.
Steps to recreate:
File dest = new File("/tmp/dir1/dir2");
File src = new File("/tmp/dir1/");
dest.mkdirs();
System.out.println(src.exists());
FileUtils.moveDirectoryToDirectory(src, dest, false);
System.out.println(src.exists());
Output:
true
false
If you try the same thing with a move command on Linux, you receive: "mv:
cannot move `dir1/' to a subdirectory of itself, `dir1/dir2/dir1'"
Maybe throw an exception if
dest.getCanonicalPath().startsWith(src.getCanonicalPath())
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-235) When running java application via procrun (in jvm mode) an RMI thread triggers an EXCEPTION_ACCESS_VIOLATION
[
https://issues.apache.org/jira/browse/DAEMON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189269#comment-13189269
]
Sebb commented on DAEMON-235:
-
If - as you suspect - the issue is due to the use of JNI by the application,
then there's not a lot the Commons Daemon team can do.
Can you remove that part of the application and see if the access violation
still occurs?
Most likely the application JNI code is not expecting to be run with the
particular security settings used by procrun, and is failing to handle the
situation correctly.
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
>
>
> Key: DAEMON-235
> URL: https://issues.apache.org/jira/browse/DAEMON-235
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.5, 1.0.6, 1.0.7, 1.0.8
> Environment: Windows XP SP3 and Win 7 SP1 x64
> JDK 1.6.0_30 Server VM (same for client) 32 bit
>Reporter: J-L
>
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
> It happens with both with a series of VM tweaking options and no options at
> all.
> Using the same options executing from a bat file (with java.exe) does not
> crash.
> The crashing application is hosting an RMI registry at the moment of the
> crash. An rmi call to the application is probably triggering the crash.
> Adding an example hs_err_pid file. (Note: the java_home pointing elsewhere
> doesn't effect the result).
> {code:none}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7824f786, pid=5876,
> tid=3656
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) Server VM (20.5-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C [MFC80.DLL+0x7f786]
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> --- T H R E A D ---
> Current thread (0x20206c00): JavaThread "RMI TCP
> Connection(2)-192.168.56.101" daemon [_thread_in_native, id=3656,
> stack(0x20ba,0x20c1)]
> siginfo: ExceptionCode=0xc005, reading address 0x21301e90
> Registers:
> EAX=0x21301e74, EBX=0x22f83170, ECX=0x22f83170, EDX=0x
> ESP=0x20c0f0c8, EBP=0x20c0f154, ESI=0x20c0f1c4, EDI=0x0004
> EIP=0x7824f786, EFLAGS=0x00010202
> Top of Stack: (sp=0x20c0f0c8)
> 0x20c0f0c8: 0002 d8a81ade 0004 20c0f1d4
> 0x20c0f0d8:
> 0x20c0f0e8: 20c0f110 206a
> 0x20c0f0f8: 00139f28
> 0x20c0f108: 0001 0027 20c0f06c 7712556e
> 0x20c0f118: 20c0f158 7c90e920 7c910060
> 0x20c0f128: 7c91005d 204cf1b7 206a
> 0x20c0f138: 22f83170 d92a86cf 0004 20c0f0cc
> Instructions: (pc=0x7824f786)
> 0x7824f766: 78 ff 75 10 e8 70 98 fa ff 85 c0 59 59 75 0a b8
> 0x7824f776: 01 00 02 80 e9 39 04 00 00 ff 75 0c 8b 03 8b cb
> 0x7824f786: ff 50 1c 85 c0 75 0a b8 ff ff 00 80 e9 21 04 00
> 0x7824f796: 00 8d 7d c8 a5 a5 a5 a5 33 ff 39 7d d4 74 18 83
> Register to memory mapping:
> EAX=0x21301e74 is an unknown value
> EBX=0x22f83170 is an unknown value
> ECX=0x22f83170 is an unknown value
> EDX=0x is an unknown value
> ESP=0x20c0f0c8 is pointing into the stack for thread: 0x20206c00
> EBP=0x20c0f154 is pointing into the stack for thread: 0x20206c00
> ESI=0x20c0f1c4 is pointing into the stack for thread: 0x20206c00
> EDI=0x0004 is an unknown value
> Stack: [0x20ba,0x20c1], sp=0x20c0f0c8, free space=444k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [MFC80.DLL+0x7f786] Ordinal3901+0x58
> C [cadxwrapper.dll+0x4e90]
> C [cadxwrapper.dll+0x519c]
> C [cadxwrapper.dll+0x133b]
> Java_com_esko_webcenter_cadxserver_CadXJNIImpl_OpenDesign+0x3b
> j
> com.esko.webcenter.cadxserver.CadXServer.generateThumbnail(Ljava/lang/String;Ljava/lang/String;)V+21
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dll+0x10e44d]
> V [jvm.dll+0x1185d3]
> V [jvm.dll+0x118f16]
> V [jvm.dll+0xc22ae]
> C [java.dll+0x7225] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x15
> j
> sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
> j
> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/
[jira] [Commented] (DAEMON-235) When running java application via procrun (in jvm mode) an RMI thread triggers an EXCEPTION_ACCESS_VIOLATION
[
https://issues.apache.org/jira/browse/DAEMON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189169#comment-13189169
]
J-L commented on DAEMON-235:
Next step in the monologue.
Tested it on a non-VM Windows machine and ran in to the same problems. So not
the VM.
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
>
>
> Key: DAEMON-235
> URL: https://issues.apache.org/jira/browse/DAEMON-235
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.5, 1.0.6, 1.0.7, 1.0.8
> Environment: Windows XP SP3 and Win 7 SP1 x64
> JDK 1.6.0_30 Server VM (same for client) 32 bit
>Reporter: J-L
>
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
> It happens with both with a series of VM tweaking options and no options at
> all.
> Using the same options executing from a bat file (with java.exe) does not
> crash.
> The crashing application is hosting an RMI registry at the moment of the
> crash. An rmi call to the application is probably triggering the crash.
> Adding an example hs_err_pid file. (Note: the java_home pointing elsewhere
> doesn't effect the result).
> {code:none}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7824f786, pid=5876,
> tid=3656
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) Server VM (20.5-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C [MFC80.DLL+0x7f786]
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> --- T H R E A D ---
> Current thread (0x20206c00): JavaThread "RMI TCP
> Connection(2)-192.168.56.101" daemon [_thread_in_native, id=3656,
> stack(0x20ba,0x20c1)]
> siginfo: ExceptionCode=0xc005, reading address 0x21301e90
> Registers:
> EAX=0x21301e74, EBX=0x22f83170, ECX=0x22f83170, EDX=0x
> ESP=0x20c0f0c8, EBP=0x20c0f154, ESI=0x20c0f1c4, EDI=0x0004
> EIP=0x7824f786, EFLAGS=0x00010202
> Top of Stack: (sp=0x20c0f0c8)
> 0x20c0f0c8: 0002 d8a81ade 0004 20c0f1d4
> 0x20c0f0d8:
> 0x20c0f0e8: 20c0f110 206a
> 0x20c0f0f8: 00139f28
> 0x20c0f108: 0001 0027 20c0f06c 7712556e
> 0x20c0f118: 20c0f158 7c90e920 7c910060
> 0x20c0f128: 7c91005d 204cf1b7 206a
> 0x20c0f138: 22f83170 d92a86cf 0004 20c0f0cc
> Instructions: (pc=0x7824f786)
> 0x7824f766: 78 ff 75 10 e8 70 98 fa ff 85 c0 59 59 75 0a b8
> 0x7824f776: 01 00 02 80 e9 39 04 00 00 ff 75 0c 8b 03 8b cb
> 0x7824f786: ff 50 1c 85 c0 75 0a b8 ff ff 00 80 e9 21 04 00
> 0x7824f796: 00 8d 7d c8 a5 a5 a5 a5 33 ff 39 7d d4 74 18 83
> Register to memory mapping:
> EAX=0x21301e74 is an unknown value
> EBX=0x22f83170 is an unknown value
> ECX=0x22f83170 is an unknown value
> EDX=0x is an unknown value
> ESP=0x20c0f0c8 is pointing into the stack for thread: 0x20206c00
> EBP=0x20c0f154 is pointing into the stack for thread: 0x20206c00
> ESI=0x20c0f1c4 is pointing into the stack for thread: 0x20206c00
> EDI=0x0004 is an unknown value
> Stack: [0x20ba,0x20c1], sp=0x20c0f0c8, free space=444k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [MFC80.DLL+0x7f786] Ordinal3901+0x58
> C [cadxwrapper.dll+0x4e90]
> C [cadxwrapper.dll+0x519c]
> C [cadxwrapper.dll+0x133b]
> Java_com_esko_webcenter_cadxserver_CadXJNIImpl_OpenDesign+0x3b
> j
> com.esko.webcenter.cadxserver.CadXServer.generateThumbnail(Ljava/lang/String;Ljava/lang/String;)V+21
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dll+0x10e44d]
> V [jvm.dll+0x1185d3]
> V [jvm.dll+0x118f16]
> V [jvm.dll+0xc22ae]
> C [java.dll+0x7225] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x15
> j
> sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
> j
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
> j
> java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
> j
> sun.rmi.server.UnicastServerRef.dispatch(Ljava/rmi/Remote;Ljava/rmi/server/RemoteCall;)V+242
> j sun.rmi.transport.Transport$1.run()Ljava/lang/Object;+23
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dl
[jira] [Commented] (DAEMON-235) When running java application via procrun (in jvm mode) an RMI thread triggers an EXCEPTION_ACCESS_VIOLATION
[
https://issues.apache.org/jira/browse/DAEMON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189081#comment-13189081
]
J-L commented on DAEMON-235:
Via this security update I was able to bring the version of MFC80 up to the
same as on Win 7.
http://www.microsoft.com/download/en/details.aspx?id=26347
But it didn't help the story.
Looking at the access violation and as a consequence turning of DEP completely
also didn't fix it.
http://www.updatexp.com/0xC005.html
I'm a strongly Java oriented developer so the whole .dll story takes a while
for me to figure out. Now it's clear to me, that MFC80 is part of the MS VC++
2005 redistributeable and procrun possibly doesn't rely on it. From the
stacktrace it looks like it is some inhouse C++ code being called via JNI that
ends up there.
That of course doesn't take away the fact that it runs correctly when using the
java.exe and not when using the procrun.exe.
Since the access exception also might imply memory errors, it's probably
important to note that the XP is running in a VirtualBox VM. I haven't been
able to test it on a non VM XP so far.
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
>
>
> Key: DAEMON-235
> URL: https://issues.apache.org/jira/browse/DAEMON-235
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.5, 1.0.6, 1.0.7, 1.0.8
> Environment: Windows XP SP3 and Win 7 SP1 x64
> JDK 1.6.0_30 Server VM (same for client) 32 bit
>Reporter: J-L
>
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
> It happens with both with a series of VM tweaking options and no options at
> all.
> Using the same options executing from a bat file (with java.exe) does not
> crash.
> The crashing application is hosting an RMI registry at the moment of the
> crash. An rmi call to the application is probably triggering the crash.
> Adding an example hs_err_pid file. (Note: the java_home pointing elsewhere
> doesn't effect the result).
> {code:none}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7824f786, pid=5876,
> tid=3656
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) Server VM (20.5-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C [MFC80.DLL+0x7f786]
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> --- T H R E A D ---
> Current thread (0x20206c00): JavaThread "RMI TCP
> Connection(2)-192.168.56.101" daemon [_thread_in_native, id=3656,
> stack(0x20ba,0x20c1)]
> siginfo: ExceptionCode=0xc005, reading address 0x21301e90
> Registers:
> EAX=0x21301e74, EBX=0x22f83170, ECX=0x22f83170, EDX=0x
> ESP=0x20c0f0c8, EBP=0x20c0f154, ESI=0x20c0f1c4, EDI=0x0004
> EIP=0x7824f786, EFLAGS=0x00010202
> Top of Stack: (sp=0x20c0f0c8)
> 0x20c0f0c8: 0002 d8a81ade 0004 20c0f1d4
> 0x20c0f0d8:
> 0x20c0f0e8: 20c0f110 206a
> 0x20c0f0f8: 00139f28
> 0x20c0f108: 0001 0027 20c0f06c 7712556e
> 0x20c0f118: 20c0f158 7c90e920 7c910060
> 0x20c0f128: 7c91005d 204cf1b7 206a
> 0x20c0f138: 22f83170 d92a86cf 0004 20c0f0cc
> Instructions: (pc=0x7824f786)
> 0x7824f766: 78 ff 75 10 e8 70 98 fa ff 85 c0 59 59 75 0a b8
> 0x7824f776: 01 00 02 80 e9 39 04 00 00 ff 75 0c 8b 03 8b cb
> 0x7824f786: ff 50 1c 85 c0 75 0a b8 ff ff 00 80 e9 21 04 00
> 0x7824f796: 00 8d 7d c8 a5 a5 a5 a5 33 ff 39 7d d4 74 18 83
> Register to memory mapping:
> EAX=0x21301e74 is an unknown value
> EBX=0x22f83170 is an unknown value
> ECX=0x22f83170 is an unknown value
> EDX=0x is an unknown value
> ESP=0x20c0f0c8 is pointing into the stack for thread: 0x20206c00
> EBP=0x20c0f154 is pointing into the stack for thread: 0x20206c00
> ESI=0x20c0f1c4 is pointing into the stack for thread: 0x20206c00
> EDI=0x0004 is an unknown value
> Stack: [0x20ba,0x20c1], sp=0x20c0f0c8, free space=444k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [MFC80.DLL+0x7f786] Ordinal3901+0x58
> C [cadxwrapper.dll+0x4e90]
> C [cadxwrapper.dll+0x519c]
> C [cadxwrapper.dll+0x133b]
> Java_com_esko_webcenter_cadxserver_CadXJNIImpl_OpenDesign+0x3b
> j
> com.esko.webcenter.cadxserver.CadXServer.generateThumbnail(Ljava/lang/String;Ljav
[jira] [Commented] (DAEMON-235) When running java application via procrun (in jvm mode) an RMI thread triggers an EXCEPTION_ACCESS_VIOLATION
[
https://issues.apache.org/jira/browse/DAEMON-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189026#comment-13189026
]
J-L commented on DAEMON-235:
So this morning I continued my investigation.
In Window 7 I can get it to run properly, if I run the service installation as
the user as whom the service will have to run (using the runas command). (I
suppose that behavior is not new. The Tomcat procrun install script makes use
of run as to install the service.)
In Windows XP the problem stays as is however.
I see that the version of the DLL differ
On Win 7
C:\Windows\WinSxS\x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.6195_none_cbf5e994470a1a8f\MFC80.DLL
On Win XP
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.4027_x-ww_b779ebd5\MFC80.DLL
I will do some attempts to change/up the version in XP
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
>
>
> Key: DAEMON-235
> URL: https://issues.apache.org/jira/browse/DAEMON-235
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.5, 1.0.6, 1.0.7, 1.0.8
> Environment: Windows XP SP3 and Win 7 SP1 x64
> JDK 1.6.0_30 Server VM (same for client) 32 bit
>Reporter: J-L
>
> When running java application via procrun (in jvm mode) an RMI thread
> triggers an EXCEPTION_ACCESS_VIOLATION
> It happens with both with a series of VM tweaking options and no options at
> all.
> Using the same options executing from a bat file (with java.exe) does not
> crash.
> The crashing application is hosting an RMI registry at the moment of the
> crash. An rmi call to the application is probably triggering the crash.
> Adding an example hs_err_pid file. (Note: the java_home pointing elsewhere
> doesn't effect the result).
> {code:none}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x7824f786, pid=5876,
> tid=3656
> #
> # JRE version: 6.0_30-b12
> # Java VM: Java HotSpot(TM) Server VM (20.5-b03 mixed mode windows-x86 )
> # Problematic frame:
> # C [MFC80.DLL+0x7f786]
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> --- T H R E A D ---
> Current thread (0x20206c00): JavaThread "RMI TCP
> Connection(2)-192.168.56.101" daemon [_thread_in_native, id=3656,
> stack(0x20ba,0x20c1)]
> siginfo: ExceptionCode=0xc005, reading address 0x21301e90
> Registers:
> EAX=0x21301e74, EBX=0x22f83170, ECX=0x22f83170, EDX=0x
> ESP=0x20c0f0c8, EBP=0x20c0f154, ESI=0x20c0f1c4, EDI=0x0004
> EIP=0x7824f786, EFLAGS=0x00010202
> Top of Stack: (sp=0x20c0f0c8)
> 0x20c0f0c8: 0002 d8a81ade 0004 20c0f1d4
> 0x20c0f0d8:
> 0x20c0f0e8: 20c0f110 206a
> 0x20c0f0f8: 00139f28
> 0x20c0f108: 0001 0027 20c0f06c 7712556e
> 0x20c0f118: 20c0f158 7c90e920 7c910060
> 0x20c0f128: 7c91005d 204cf1b7 206a
> 0x20c0f138: 22f83170 d92a86cf 0004 20c0f0cc
> Instructions: (pc=0x7824f786)
> 0x7824f766: 78 ff 75 10 e8 70 98 fa ff 85 c0 59 59 75 0a b8
> 0x7824f776: 01 00 02 80 e9 39 04 00 00 ff 75 0c 8b 03 8b cb
> 0x7824f786: ff 50 1c 85 c0 75 0a b8 ff ff 00 80 e9 21 04 00
> 0x7824f796: 00 8d 7d c8 a5 a5 a5 a5 33 ff 39 7d d4 74 18 83
> Register to memory mapping:
> EAX=0x21301e74 is an unknown value
> EBX=0x22f83170 is an unknown value
> ECX=0x22f83170 is an unknown value
> EDX=0x is an unknown value
> ESP=0x20c0f0c8 is pointing into the stack for thread: 0x20206c00
> EBP=0x20c0f154 is pointing into the stack for thread: 0x20206c00
> ESI=0x20c0f1c4 is pointing into the stack for thread: 0x20206c00
> EDI=0x0004 is an unknown value
> Stack: [0x20ba,0x20c1], sp=0x20c0f0c8, free space=444k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C [MFC80.DLL+0x7f786] Ordinal3901+0x58
> C [cadxwrapper.dll+0x4e90]
> C [cadxwrapper.dll+0x519c]
> C [cadxwrapper.dll+0x133b]
> Java_com_esko_webcenter_cadxserver_CadXJNIImpl_OpenDesign+0x3b
> j
> com.esko.webcenter.cadxserver.CadXServer.generateThumbnail(Ljava/lang/String;Ljava/lang/String;)V+21
> v ~StubRoutines::call_stub
> V [jvm.dll+0x10e3bd]
> V [jvm.dll+0x1a5711]
> V [jvm.dll+0x10e44d]
> V [jvm.dll+0x1185d3]
> V [jvm.dll+0x118f16]
> V [jvm.dll+0xc22ae]
> C [java.dll+0x7225] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x15
> j
> sun.
