Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Standalone developer-studio pack
We try but get 


[0224/173422:ERROR:browser_main_loop.cc(163)] Running without the SUID sandbox! See https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment for more information on developing with the sandbox on.
[0224/173422:INFO:audio_manager_pulse.cc(258)] Failed to connect to the context.  Error: Connection refused
*** buffer overflow detected ***: /home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio terminated
======= Backtrace: =========
/lib64/libc.so.6(+0x7410f)[0x7ff30cf1510f]
/lib64/libc.so.6(__fortify_fail+0x37)[0x7ff30cf99657]
/lib64/libc.so.6(+0xf6800)[0x7ff30cf97800]
/lib64/libc.so.6(+0xf6de4)[0x7ff30cf97de4]
/home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio[0x4039fd]
/home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio[0x407a9b]
./libcef.so(+0x659f1c)[0x7ff30e10df1c]
./libcef.so(+0x659955)[0x7ff30e10d955]
./libcef.so(+0x6595b2)[0x7ff30e10d5b2]
./libcef.so(cef_initialize+0xc6)[0x7ff30e0bd416]
/home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio[0x406474]
/home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio[0x402db5]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ff30cec2be5]
/home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio[0x40329e]
======= Memory map: ========
00400000-0043b000 r-xp 00000000 08:03 2498170                            /home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio
0063b000-00644000 r--p 0003b000 08:03 2498170                            /home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio
00644000-00645000 rw-p 00044000 08:03 2498170                            /home/vetal/wso2/wso2-developer-studio-linux64/bin/wso2devstudio




Vitaly Parfonov -- codenvy

On Tue, Feb 24, 2015 at 3:28 PM, Awanthika Senarath <awanthika@xxxxxxxx> wrote:
Hi Vitalli, 

The package amounts to 400MB can you give us an FTP location to upload this? I am unable to share this..

Or else checkout the source from [1], build using "maven clean install" and you can find the binary in cloud-dev-studio/assembly/org.wso2.developerstudio.distribution.assembly/target

unzip the wso2-developer-studio-linux64/ and copy the binaries in the release zip I have shared with you into the bin of the unzipped developer studio distribution. then run as ./wso2devstudio from bin. 

This will contain the error. If you replace the codenvy-jdt-core-repack-1.5.0.jar as I have mentioned in the previous mail with codenvy-jdt-core-repack-1.2.0.jar from codenvy sdk 3.2.0 you can see that the error goes away..

 Please let us know if you want any details on this.



On Tue, Feb 24, 2015 at 3:50 PM, Vitalii Parfonov <vparfonov@xxxxxxxxxxx> wrote:
Hi, all
Can you provide package? We need check on our side.
Thanks

Vitaly Parfonov -- codenvy

On Tue, Feb 24, 2015 at 5:20 AM, Awanthika Senarath <awanthika@xxxxxxxx> wrote:
Hi Codenvy team,

To be precise we narrowed down the issue to be related to codenvy-jdt-core-repack-1.5.0.jar in sdk 3.5.0. When we replaced that jar with the jar in sdk 3.2.0 (which is codenvy-jdt-core-repack-1.2.0.jar) the issue is solved..

regards
Awanthika

On Tue, Feb 24, 2015 at 8:39 AM, Awanthika Senarath <awanthika@xxxxxxxx> wrote:
Hi all,

Apparently there has been a version upgrade in the jdt related jars when moving from sdk 3.2.0 to sdk 3.5.0. After many attempts we got the issue solved by replacing the relevant jdt jars in 3.5.0 named below by the ones that are used in 3.2.0. It appears as if your version upgrade in these related jars is causing the issue..

jdt related jars in 3.2.0

codenvy-jdt-core-repack-1.2.0.jar
org.eclipse.jdt.core-3.9.0.v20130604-1421.jar


jdt related jars in 3.5.0

codenvy-jdt-core-repack-1.5.0.jar
org.eclipse.jdt.core-3.10.0.v20140604-1726.jar

Appreciate your help on getting this fixed permanently ...

regards
Awanthika

On Mon, Feb 23, 2015 at 6:54 PM, Dmitry Kuleshov <dkuleshov@xxxxxxxxxxx> wrote:
Hi,

Adding to che-dev@xxxxxxxxxxx

With regards,
Dmitry

2015-02-23 13:59 GMT+02:00 Evgen Vidolob <evidolob@xxxxxxxxxxx>:
java.lang.IllegalAccessError: tried to access field org.eclipse.jdt.internal.compiler.SourceElementNotifier.requestor from class org.eclipse.jdt.internal.compiler.SourceElementParser
at org.eclipse.jdt.internal.compiler.SourceElementParser.setRequestor(SourceElementParser.java:998)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.SourceIndexer.indexDocument(SourceIndexer.java:93)
at com.codenvy.ide.ext.java.server.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:94)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:559)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:1021)
at com.codenvy.ide.ext.java.server.internal.core.search.processing.JobManager.run(JobManager.java:417)
at java.lang.Thread.run(Thread.java:745)
This error may happen when you use wrong version of  org.eclipse.jdt.core library. All error that you see in editor is related to this stack trace, our server side can't build proper index of java project, so editor can't find proper information about classes and packages.

We upgrade to latest version of eclipse libraries somewhere between 3.2 and 3.5, so all changes in StandardVMType.java related to this upgrade.

2015-02-23 13:03 GMT+02:00 Awanthika Senarath <awanthika@xxxxxxxx>:
Hi Codenvy team,

We have tested this with che 3.6.0 and the issue persists. To give you a basic overview the logs we get on starting up the stand-alone che :

015-02-23 11:05:51 ERROR Launching:192 - Failed to retrieve default libraries for /usr/lib/java/jdk1.7.0_71
2015-02-23 11:05:53 ERROR Util:225 - Background Indexer Crash Recovery
java.lang.IllegalAccessError: tried to access field org.eclipse.jdt.internal.compiler.SourceElementNotifier.requestor from class org.eclipse.jdt.internal.compiler.SourceElementParser
at org.eclipse.jdt.internal.compiler.SourceElementParser.setRequestor(SourceElementParser.java:998)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.SourceIndexer.indexDocument(SourceIndexer.java:93)
at com.codenvy.ide.ext.java.server.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:94)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:559)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:1021)
at com.codenvy.ide.ext.java.server.internal.core.search.processing.JobManager.run(JobManager.java:417)
at java.lang.Thread.run(Thread.java:745)

We have tested and verified that both the above logged errors are not related to the problem at hand. The first error log line is there even in the cloud che version where the syntax error is not there. error log line 2 is there in standalone version 3.2.0 where again the error is not occurring..

Hence I believe we can ignore those..

Could you please give us some insight on the following concerns ?

(1) Is it possible that even though these logged errors can be ignored in eclipse_che on browser it has some effect when we run the application inside a CEF browser that ew get these syntax resolution errors?
(2) we have noticed that if we up the embedded che sdk (3.5.0) from che.sh it will load successfully with our extensions, yet if we run it with our sh file we get the syntax errors in projects created. I have attached the sh file from which we run the Codenvy for your reference
(3) if not, you have any idea why the issue (of which I have attached a screenshot) re-appeared with sdk 3.5.0?
(4) we noticed that you have done changes to the code-assistance StandardVMType.jar from 3.2.0 to 3.5.0 could this have any relation to what we are facing ?

really appreciate your feedback on this as we are facing a blocker with this situation 


​

regards
Awanthika 


On Mon, Feb 23, 2015 at 4:30 PM, Awanthika Senarath <awanthika@xxxxxxxx> wrote:
Hi Codenvy team,

We have tested this with che 3.6.0 and the issue persists. To give you a basic overview the logs we get on starting up the stand-alone che :

015-02-23 11:05:51 ERROR Launching:192 - Failed to retrieve default libraries for /usr/lib/java/jdk1.7.0_71
2015-02-23 11:05:53 ERROR Util:225 - Background Indexer Crash Recovery
java.lang.IllegalAccessError: tried to access field org.eclipse.jdt.internal.compiler.SourceElementNotifier.requestor from class org.eclipse.jdt.internal.compiler.SourceElementParser
at org.eclipse.jdt.internal.compiler.SourceElementParser.setRequestor(SourceElementParser.java:998)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.SourceIndexer.indexDocument(SourceIndexer.java:93)
at com.codenvy.ide.ext.java.server.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:94)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:559)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:1021)
at com.codenvy.ide.ext.java.server.internal.core.search.processing.JobManager.run(JobManager.java:417)
at java.lang.Thread.run(Thread.java:745)

We have tested and verified that both the above logged errors are not related to the problem at hand. The first error log line is there even in the cloud che version where the syntax error is not there. error log line 2 is there in standalone version 3.2.0 where again the error is not occurring..

Hence I believe we can ignore those..

Could you please give us some insight on the following concerns ?

(1) Is it possible that even though these logged errors can be ignored in eclipse_che on browser it has some effect when we run the application inside a CEF browser that ew get these syntax resolution errors?
(2) we have noticed that if we up the embedded che sdk (3.5.0) from che.sh it will load successfully with our extensions, yet if we run it with our sh file we get the syntax errors in projects created. I have attached the sh file from which we run the Codenvy for your reference
(3) if not, you have any idea why the issue (of which I have attached a screenshot) re-appeared with sdk 3.5.0?
(4) we noticed that you have done changes to the code-assistance StandardVMType.jar from 3.2.0 to 3.5.0 could this have any relation to what we are facing ?

really appreciate your feedback on this as we are facing a blocker with this situation 

regards
Awanthika 











On Mon, Feb 23, 2015 at 8:27 AM, Susinda Perera <susinda@xxxxxxxx> wrote:
Hi Tyler

I checked with 3.6.0 but issue is exists there too.

Thanks

On Fri, Feb 20, 2015 at 8:21 PM, Susinda Perera <susinda@xxxxxxxx> wrote:
No, I'll give a try on 3.6.0 hope there's no much differences from 3.5 to 3.6.

Thanks

On Fri, Feb 20, 2015 at 6:14 PM, Tyler Jewell <tyler@xxxxxxxxxxx> wrote:
I believe this issue was fixed in the 3.6.0 branch.  And we will be making 3.7.0 release next week as well.  Any chance that you can migrate to this version or do you need the issue back ported?

Vitalii is on holiday this week, returning on Monday.

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55


On Fri, Feb 20, 2015 at 1:19 AM, Susinda Perera <susinda@xxxxxxxx> wrote:
Hi Vitalii

Above error[1] i posted is there in 3.2.0 also, So i think syntax highlight issue and error[1] is not related.
Appreciate some help form your side to fix the same in 3.5.0. 


Thanks 

On Fri, Feb 20, 2015 at 1:57 PM, Susinda Perera <susinda@xxxxxxxx> wrote:
Hi Vitallii

We have moved to use sdk version 3.5.0 and again we get the same syntax highlight issue. Error i saw in the back-end is[1]. I'm not sure whether the issue is because of [1] or not. Hope you might have some idea. 

[1]
 Util:225 - Background Indexer Crash Recovery
java.lang.IllegalAccessError: tried to access field org.eclipse.jdt.internal.compiler.SourceElementNotifier.requestor from class org.eclipse.jdt.internal.compiler.SourceElementParser
at org.eclipse.jdt.internal.compiler.SourceElementParser.setRequestor(SourceElementParser.java:998)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.SourceIndexer.indexDocument(SourceIndexer.java:93)
at com.codenvy.ide.ext.java.server.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:94)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:559)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:1021)
at com.codenvy.ide.ext.java.server.internal.core.search.processing.JobManager.run(JobManager.java:417)
at java.lang.Thread.run(Thread.java:722)
Exception in thread "Java indexing" java.lang.IllegalAccessError: tried to access field org.eclipse.jdt.internal.compiler.SourceElementNotifier.requestor from class org.eclipse.jdt.internal.compiler.SourceElementParser
at org.eclipse.jdt.internal.compiler.SourceElementParser.setRequestor(SourceElementParser.java:998)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.SourceIndexer.indexDocument(SourceIndexer.java:93)
at com.codenvy.ide.ext.java.server.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:94)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:559)
at com.codenvy.ide.ext.java.server.internal.core.search.indexing.IndexManager$1.execute(IndexManager.java:1021)
at com.codenvy.ide.ext.java.server.internal.core.search.processing.JobManager.run(JobManager.java:417)
at java.lang.Thread.run(Thread.java:722)

On Mon, Feb 9, 2015 at 10:18 AM, Vitalii Parfonov <vparfonov@xxxxxxxxxxx> wrote:

Great, thanks for info.

9 февр. 2015 г. 6:39 пользователь "Kavith Lokuhewage" <kavith@xxxxxxxx> написал:

Hi Vitalli,

We were able to fix this class loading issue and now it works fine. Thanks a lot for your support.

Best,

On Tue, Jan 27, 2015 at 10:14 PM, Vitalii Parfonov <vparfonov@xxxxxxxxxxx> wrote:
Yes it think so. 

I don't know how class loading work then you do this org.wso2.developerstudio.server.launcher.DevsTomcatServer#addWebapp 

Vitaly Parfonov -- codenvy

On Tue, Jan 27, 2015 at 6:37 PM, Kavith Lokuhewage <kavith@xxxxxxxx> wrote:
Hi Vitalli,

Thanks for finding the issue. Can the root cause be a problem related to using Tomcat in embedded mode (since Tomcat is using System class loader instead of its own loaders)?

Thanks.

On Tue, Jan 27, 2015 at 9:20 PM, Vitalii Parfonov <vparfonov@xxxxxxxxxxx> wrote:
Hello, Kavith,

Yep i already start debug mode on other machine. And looks like found the problem. As we suppose problem is with class loading. 
I set breakpoint in line 998 in org.eclipse.jdt.internal.compiler.SourceElementParser  (from webapps/java-ca/WEB-INF/lib/codenvy-jdt-core-repack-1.5.0.jar) 
and see that we have two different classloader and class from child classloader try modify class from parent classloader.

Bellow I show getClass().getProtectionDomain() 

First:
 (file:/home/roman/java/projects/wso2/cloud-dev-studio/assembly/org.wso2.developerstudio.distribution.assembly/target/wso2-developer-studio-linux64/webapps/java-ca/WEB-INF/lib/codenvy-jdt-core-repack-1.5.0.jar <no signer certificates>)
 WebappClassLoader
  context: /java-ca
  delegate: false
  repositories:
    /WEB-INF/classes/
----------> Parent Classloader:
sun.misc.Launcher$AppClassLoader@5cfab5b1

 <no principals>
 java.security.Permissions@bc28afe (
 ("java.io.FilePermission" "/home/roman/java/projects/wso2/cloud-dev-studio/assembly/org.wso2.developerstudio.distribution.assembly/target/wso2-developer-studio-linux64/webapps/java-ca/WEB-INF/lib/codenvy-jdt-core-repack-1.5.0.jar" "read")
)


Second:

ProtectionDomain  (file:/home/roman/java/projects/wso2/cloud-dev-studio/assembly/org.wso2.developerstudio.distribution.assembly/target/wso2-developer-studio-linux64/lib/ecj-3.7.2.jar <no signer certificates>)
 sun.misc.Launcher$AppClassLoader@5cfab5b1
 <no principals>
 java.security.Permissions@4e4bf46a (
 ("java.lang.RuntimePermission" "exitVM")
 ("java.io.FilePermission" "/home/roman/java/projects/wso2/cloud-dev-studio/assembly/org.wso2.developerstudio.distribution.assembly/target/wso2-developer-studio-linux64/lib/ecj-3.7.2.jar" "read")
)


SourceElementNotifier.class load from ecj-3.7.2.jar but same class exist in odenvy-jdt-core-repack-1.5.0.jar.


Hope you understand that i try explain. :)

P.S. I don't have solutions for now only indicate the problem.


Vitaly Parfonov -- codenvy

On Tue, Jan 27, 2015 at 5:25 PM, Kavith Lokuhewage <kavith@xxxxxxxx> wrote:
Hi Vitalli,

I can see a file named pid in your bin folder. This indicates that DeveloperStudio has crashed some where and failed to delete this pid file before exit. This file is written by java server launcher so that the upon application exit, native application can shutdown tomcat properly.

Please kill the process with pid in this file, delete it and restart DeveloperStudio. We may have to look into the cause for this issue. Please share the results.

Thanks.

On Tue, Jan 27, 2015 at 6:45 PM, Vitalii Parfonov <vparfonov@xxxxxxxxxxx> wrote:
Hello again! I apologize for my molestation. But i already try way that you propose. But in this case DevStudio don't start, i see it in process list but don't see main screen. I have record video please see.


Thanks

Vitaly Parfonov -- codenvy

On Tue, Jan 27, 2015 at 2:19 PM, Kavith Lokuhewage <kavith@xxxxxxxx> wrote:
Hi Vitalii,

Please see my comments in-line.

On Tue, Jan 27, 2015 at 2:56 PM, Vitalii Parfonov <vparfonov@xxxxxxxxxxx> wrote:
Yes i have this file. I just don't understand that need copy it manually. 

Yes, we are working on to host these binaries somewhere (probably in our nexus) and configure our poms to fetch them automatically. We are still improving the build and sorry for the trouble. :)

 

Sorry, but i mean not logging level. I need connect with remote debug for checking class loading problem. I need set somewhere props like this but don't know there 


-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000 

Sorry, I misunderstood that you are talking about logs. As I mentioned before, still there are lot of improvements to be done for the standalone version and this is another case that needs improvement. We are planning to implement a console argument forwarding mechanism from native applications to shell scripts and then to java components. There, we are thinking of to use a console flag to enable debug mode while launching the native executable.

However, this can be easily achieved by modifying server.sh file. Please add those props as args to exec command found in the bottom of server.sh file.

After modifying, it will look like this.

exec "$JAVACMD" $JAVA_OPTS  \
  -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n \
  -classpath "$CLASSPATH" \
...

This will enable remote debug mode. Also, please refer to attached server.sh file that already has been modified.

Thanks.
--
Kavith Lokuhewage
Software Engineer
WSO2 Inc. - http://wso2.com
lean . enterprise . middleware
Mobile - +9477-9-145-123 | +9471-455-6-401




--
Kavith Lokuhewage
Software Engineer
WSO2 Inc. - http://wso2.com
lean . enterprise . middleware
Mobile - +9477-9-145-123 | +9471-455-6-401




--
Kavith Lokuhewage
Software Engineer
WSO2 Inc. - http://wso2.com
lean . enterprise . middleware
Mobile - +9477-9-145-123 | +9471-455-6-401




--
Kavith Lokuhewage
Software Engineer
WSO2 Inc. - http://wso2.com
lean . enterprise . middleware
Mobile - +9477-9-145-123 | +9471-455-6-401



--
Susinda Perera
Software Engineer
Mobile:(+94)716049075

WSO2 Inc. http://wso2.com/
Tel : 94 11 214 5345 Fax :94 11 2145300




--
Susinda Perera
Software Engineer
Mobile:(+94)716049075

WSO2 Inc. http://wso2.com/
Tel : 94 11 214 5345 Fax :94 11 2145300





--
Susinda Perera
Software Engineer
Mobile:(+94)716049075

WSO2 Inc. http://wso2.com/
Tel : 94 11 214 5345 Fax :94 11 2145300




--
Susinda Perera
Software Engineer
Mobile:(+94)716049075

WSO2 Inc. http://wso2.com/
Tel : 94 11 214 5345 Fax :94 11 2145300




--
Awanthika Senarath
Software Engineer, WSO2 Inc.
Mobile: +94717681791





--
Awanthika Senarath
Software Engineer, WSO2 Inc.
Mobile: +94717681791







--
Awanthika Senarath
Software Engineer, WSO2 Inc.
Mobile: +94717681791





--
Awanthika Senarath
Software Engineer, WSO2 Inc.
Mobile: +94717681791






--
Awanthika Senarath
Software Engineer, WSO2 Inc.
Mobile: +94717681791



Back to the top