JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #41  
Old 03.10.2010, 22:13
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

thanks statter, that was helpful...
Reply With Quote
  #42  
Old 04.10.2010, 11:51
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Arrow Emergency Log

Post 12 is incorrect.
Corrected instructions for posting an emergency log in OS-X
Create a script containing the following:
Code:
#bash
cd /applications/jdownloader.app
java -verbose -jar jdownloader.jar -debug -brdebug 1> jd_out.log 2> jd_err.log
Create an archive from the two log files.
Open a message describing the problem, the computing environment, and listing the links.
Use Go Advanced and Manage Attachments (Browser and then Upload) to attach the archive.

Return to the message and send it.

Last edited by drbits; 04.10.2010 at 11:55.
Reply With Quote
  #43  
Old 04.10.2010, 11:57
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by drbits View Post
Post 12 is incorrect.
Corrected instructions for posting an emergency log in OS-X
Create a script containing the following:
Code:
#bash
cd /applications/jdownloader.app
java -verbose -jar jdownloader.jar -debug -brdebug 1> jd_out.log 2> jd_err.log
Create an archive from the two log files.
Open a message describing the problem, the computing environment, and listing the links.
Use Go Advanced and Manage Attachments (Browser and then Upload) to attach the archive.

Return to the message and send it.
what is the correct time i can produce this log?
before starting JD, when running JD, or after JD freezes the whole system and i press on/off button for 10sec to reboot, so, after the reboot?
Reply With Quote
  #44  
Old 05.10.2010, 15:04
freezingiMac
Guest
 
Posts: n/a
Default

So, I've been keeping busy and have come up with new results:

VM: I set up JD in a fresh VirtualBox VM running Ubuntu 10.04 Netbook Edition with about 1 GB RAM. It let it run over night and when I checked the next morning not only the VM was completely frozen but it had somehow managed to freeze Mac OS X as well! My HFS+ partition was alright this time of course.


Mac OS X: So, after giving up the VM idea, I did the following: I redownloaded JD to make sure the app container is not corrupted. I scanned my hard drive with Drive Genius which yielded no disk errors. My system is up to date according to Apple Software Update. AppleJack also reported that everything is alright.
One thing I noticed though: Every time I repaired permissions after a system freeze caused by JD there were exactly two permissions Disk Utility (and AppleJack) reported as being wrong:

deploy.jar (was lrwxr-xr-x, should be -rw-r--r--) and libdeploy.jnilib (was lrwxr-xr-x, should be -rwxr-xr-x), both in /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Resources/JavaPluginCocoa.bundle/Contents/Resources/Java

My guess is these permissions are changed by Java as soon as JD is launched, as these permission changes not only occurred after a freeze and hard reset.


Last night I wanted to do things right and set up JD to log everything (logs are attached). I also wrote an AppleScript to take screenshots every two minutes (also attached) but it did not record anything while the screen was off tonight *g* (I wanted to monitor RAM and CPU usage as well as JD). As you can see in the second screenshot attached (taken right after the screen "woke up" today) there is a lot of free memory, CPU is idle and everything seems to be in order. But still, all applications were extremely unresponsive. In the end I managed to force quit JD and did not have to hard reset the Mac this time. On thing is also worth noting: On every freeze my internet connection stopped working. This was also the case today, when I was able to "recover" from JD freezing the system. The only thing that helped to get me back online was rebooting Mac OS X.


Regarding Rosetta: Did I get that right, someone already tried running JD/Java under Rosetta und the system still froze? And concerning the 64bit/32bit kernel question: I could startup Mac OS X in "true" 64bit mode but since the JD/Java process is already 64bit, what's the point?

@50cmvorm50"plasma: I let JD log until I force quit it today.
Attached Files
File Type: zip LogsAndScreenshots.zip (546.6 KB, 343 views)
Reply With Quote
  #45  
Old 05.10.2010, 16:13
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

ok i see freezingimac...thanks

i cant report anything other than my JD is running smooth since i changed checkmark to "rosetta" and run in "32bit" and also run both Java´s RE in 32bit in java app.

although i didnt let it run continously longer than 45minutes, and stopped waiting for 5minutes to help recovering "him" from high load & work, until i proceeded, cause i am still afraid of getting my imac frozen, this procedure is successfull - i guess i should let JD run for some hours continously to prove that its not freezing my system anymore. i hope...

additionally i usually quit all other apps before opening JD
last month i removed JD and installed a new JD fresh install, like you...
i did that a couple of times since january, but it maybe didnt help...
Reply With Quote
  #46  
Old 06.10.2010, 07:16
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

JD should be run in 32 bit Java. I think there are some bugs in Apple's 64 bit Java Virtual Machine (JVM). In addition, almost all programs run just as well in 32 bit mode as in 64 bit mode (unless they need more than 2 GB of memory). There is no significant speed improvement in 64 bit mode and most Java programs run slower in 64 bit mode. This is for all OS.

I believe you can install both 64 bit Java and 32 bit Java. However, it might be important to install the 32 bit Java last. Programs "compiled" for 64 bit Java will still find the correct Java directory, but installing Java in the wrong order can break the 32 bit Java.

Installing both versions of Java on the same file system might be causing the soft-link creation. These links might not be errors, but may be the result of Java fixing the installation (it might be that only one copy of each file may exist, so Java creates a link).

You probably know that the directory entry (containing a file name and I-node number) and the file information (I-node) are separate in *nix (including OS-X) and NTFS. The protection lives in the I-node, not the directory. A soft-link file only contains the file path of the file it refers to. Forcing a change in the protection can break things, even if AppleJack or Clean (the *nix equivalent) report that the protection is incorrect. In particular, all *.class, *.jar, *.jni, and *.jnilib files must be executable. You should have a *nix utility that allows you to view the actual contents of an I-node and the file it represents. If you change the protection bits on a jar file to remove the soft-link bit and view the file, you will either see that it is a file path (it really is a soft link) or that it starts with PK (jar files are zip files).
________________________________________

If the OS is frozen or crashed, that means that there is a bug in the kernel. The fact that Java can trigger the freeze does not mean there is something wrong in Java (although both the kernel and JVM should be changed to avoid the freeze). It is very unlikely that JDownloader is triggering the freeze, unless there is jni code that is working around a problem with OS-X.

When the system is slow, but not frozen, you can collect information about the situation. If you download the Java Development Kit (JDK), you can use jconsole or jvisualvm to create a stack dump. This will show the stack for each of the threads in JDownloader. If you zip this file and attach it to a message, that can help us figure out what is happening.

For example, if you have Max.Con.=1 and Max.Dls.<5, then the total number of active threads in JDownloader should be less than 50 (not including Zombies or Ghosts). If the thread count continues to rise over time, that could cause the computer to slow down. Similar problems could happen if files are not closed or of the overall size of the program keeps growing.
__________________________________

Please contact Apple about the kernel freeze and the problems with the disk utility.
Reply With Quote
  #47  
Old 06.10.2010, 08:51
Statter Statter is offline
JD VIP
 
Join Date: Aug 2010
Posts: 455
Default

Actually Apple OS Java 1.5.x and 1.6.x is already a combined 32/64 bit install.
See :**External links are only visible to Support Staff** and "http://www.java.com/en/download/manual.jsp"

Snow Leopard defaults to 32 bit mode on start up.
You have to explicitly tell it to run in 64 bit mode either by holding down keys on startup ( "6" & "4" ??) or manually setting a preference.

Snow Leopard runs 32-bit system software and applications on 32-bit Intel machines, and 64-bit system software and 32-bit and 64-bit applications on 64-bit Intel machines.

The desktop version of Snow Leopard by default boots a 32-bit kernel for reasons of kext and driver compatibility, but all user space runs 64-bit. this has to be changed manually to boot to 64 bit. In doing so one may need to still run some items in 32 bit mode for some compatibility issues.

Mac OS X Server boots into a 64-bit kernel. Core 2 Duo is a 64-bit machine.

Try $ sysctl hw.cpu64bit_capable or sysctl hw.optional.x86_64 to verify that you have a 64-bit cpu. arch will always show i386 on Intel hardware in both Leopard and Snow Leopard.

The app I pointed out in an earlier post also helps determine wether one in Snow Leopard is actually booting or is switchable from 32 bit to 64 boot up mode without having to get into terminal. Note this app only runs in Snow Leopard and above.

That being said JD seems to run better in 32 bit versus 64 bit in OS X. There are still a few other apps also wether they be Java or not that still atm tend to run better in the 32 bit mode selectable by the get info and run in 32 bit mode selection.

Some apps also tend to run better in the Rosetta mode although they will run under Snow Leopard in native mode. Usually if an app is needed to be put into either the Rosetta or 32 bit run mode it is because the app or some underlying process has not been properly built to begin with to fully take on the full native mode environment.

Now as for the permissions noted regarding such as (was lrwxr-xr-x, should be -rw-r--r--) or (was lrwxr-xr-x, should be -rwxr-xr-?) the "l" is noting that this relationship is actually a symbolic link for pointing to the correct/current versions of components to run properly.

Files that aren't installed as part of an Apple-originated installer package are not listed in a receipt and therefore are not checked for permissions.

For example, if you install an application using a non-Apple installer application, or by copying it from a disk image, network volume, or other disk instead of installing it via Installer, a receipt file isn't created. This is expected. Some applications are designed to be installed in one of those ways.

Unless something has been installed to change some permissions that are different from the symbolic link (usually it is an install that is not set properly in the first place to change the dbase of installed permissions for the file when it is actually installed in the first place.

Also, certain files whose permissions can be changed during normal usage without affecting their function are intentionally not checked.

One can manually change such through terminal but it is recommended to not mess with something regarding permissions at the root level unless you really know what is what as if you allow or change the permissions incorrectly you could do one of two things.
1. You could break the true functionality and the effectiveness of the app calling such.
2. You could open the doors to an outside influence that could allow full root access leading to a possible trojan/virus or other attack.

Most of the times such permission errors can be ignored as pointed out here > "**External links are only visible to Support Staff** and you may wish to also review this article > "**External links are only visible to Support Staff**

I'm sure I'm forgetting something but getting tired and so will leave it here and quit writing a min novel.

Hopefully this will help clarify for some the issues they may be confused with.
__________________
OS X !0.6.8 Mac Pro Intel (Workhorse)
OS X 10.10.5 MBP Intel (Secondary)

Last edited by Statter; 06.10.2010 at 08:54.
Reply With Quote
  #48  
Old 13.10.2010, 01:40
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

thanks @ all !

i understand.

JD seems to be running fine since 2 weeks, without any freezes - since i enabled 32bit & "run in rosetta" in "about JD info in finder" and set java to 32bit.

additionally i am installing snowleopard over my system,
to clean the kernel..

all right here...
Reply With Quote
  #49  
Old 17.10.2010, 16:17
freezingiMac
Guest
 
Posts: n/a
Default

@50cm: Thanks, I'm gonna try it your way.
I was just wondering: I turned on "Open using Rosetta" in JD info but Activity Monitor says JD is of kind "Intel". Is this right?
Reply With Quote
  #50  
Old 17.10.2010, 16:47
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

i dont know sorry,
just run it, for myself, it works so far...
Reply With Quote
  #51  
Old 20.10.2010, 08:35
Statter Statter is offline
JD VIP
 
Join Date: Aug 2010
Posts: 455
Default

@freezingiMac
Theoretically it should be fine without using Rosetta but, depending on OS version it may be better to use if it is available.

For example in 10.5.x Rosetta is grayed out for the app while run in 32 bit is not grayed out. In 10.5.x one does not need to run in 32bit as that is default for the OS to begin with.

with 10.6.x some of the backward compatibility was removed and thus sometimes some apps may need to be run now under Rosetta. In 10.6.x the OS may run in either 32 bit or 64 bit depending on what is enabled or not ... Default install for most OS 10.6.x though is 32bit which of course can be changed to run in 64bit. In this case with 10.6.x regardless of 32 bit OS or 64bit OS most apps if programed for 64 bit will run in 64bit. Due to problems with Java etc it is often best to set some apps to run under 32 bit.

In other words you can test it either way with/without Rosetta (you may find it is needed or maybe it isn't needed-This is sometimes an affect f which actual machine you have, so testing is the only real way to see if Rosetta is needed or not for some apps.) and you will probably find that JD will run better when set to run in 32bit mode.
__________________
OS X !0.6.8 Mac Pro Intel (Workhorse)
OS X 10.10.5 MBP Intel (Secondary)
Reply With Quote
  #52  
Old 20.10.2010, 10:41
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

yes true, i am using 10.6 snowleo. since it has been published,
and JD runs still fine in 32bit, also rosetta is checked, and my java is set to 32bit. i didnt have freezes since i operate like this.
lets hope it stays freezeless for a longer period of time.

will JD also run fine in 64bit with java64bit in the future?
or does this depend on apple and java?
Reply With Quote
  #53  
Old 14.01.2011, 21:12
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

freezes now again.
dont know why, sorry. i am helpless.

i didnt change any setting, i just sold my imac and bought a brand new mbp 2,66 i7 15".
so i installed snow leo latest version 10.6.6 and JD running in rosetta 32bit mode, also java is set to 32bit.
it freezes after 30 or 60 min. i cannot operate any button, as the screen/mbp is completely frozen, have to press on/off button for 10sec. then it reboots...

i wonder - are all of you guys running lower system versions like 10.5 or 10.4 on older machines?
maybe JD isnt running properly on new apple machines with 10.6.6. right?

i am repairing permissions every day in apple+s save boot mode.
also my apple computer is brand new, so i didnt install other crapsoft on it.
i wonder why it still freezes, any idea?

Last edited by 50cmvorm50"plasma; 14.01.2011 at 21:16.
Reply With Quote
  #54  
Old 15.01.2011, 07:37
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

This cannot be a JDownloader bug. Java will not allow JDownloader to cause this kind of problem. However, if Java has a problem, JDownloader may exercise that part of Java, while most programs would not.

JD works fine in 64 bit Java, however 64 bit Java is not as efficient. You might have to download an older Java release (on PCs this is a major problem, but it should not be in OS-X). If you can obtain Java 32 bit JRE 6 update 21, that might help.

Apple's modifications should have fixed any display inconsistencies, but you might try a script:
Code:
cd <path to jdownloader>
<path to Java>/bin/javaw -Dsun.java2d.ddscale=true -jar jdownloader.jar
The -D parameter turns off attempts to use the 3D part of the Video Adapter.

If you are still getting system freezes, please attach an Emergency Log to a message and we will look for problems there.

System freezes are usually caused by inconsistencies between hardware and drivers (if you have them installed, antivirus and firewall programs count as drivers). Please check for OS updates. Check to see if you have any unusual components, such as an unusual video card or RAM controller update (e.g., 3 channel DDR3 with only two RAM cards).
__________________
Please, in each Forum, Read the Rules!.Helpful Links. Read before posting.
Reply With Quote
  #55  
Old 21.03.2011, 11:34
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

i am sorry, dr.bits , i didnt check, as i migrated from my old imac to my new mbp.
so i had to check "open in 32bit" and "start under ROSETTA" in JD app (apple+i)
now it wont freeze my whole mbp, it suddenly freezes JD after 1 h running, but now
i can quit JD with "quit task" key-kombo.

when i toggle off these checks ""open in 32bit" and "open under ROSETTA"
it will freeze my whole mbp.

under java i checked 32bit and not 64bit.

why do i have these problems with JD on 2 computers so far, and all others are running JD in 64bit under 10.6.6 fine?

will JD never be updated so that i can run it without checking "open in 32bit" and "start under ROSETTA" and setting java to 64bit in java app settings?

thanks

ps: i didnt install any antivirus or other drivers software ( i only run little snitch)
Reply With Quote
  #56  
Old 21.03.2011, 11:42
remi
Guest
 
Posts: n/a
Default

I would recommend providing Emergency Logs for those freezes.
Reply With Quote
  #57  
Old 14.04.2011, 00:47
50cmvorm50"plasma
Guest
 
Posts: n/a
Default

now it works with latest 10.6.7!

since 10.6.7, i run JD smoothly with java SE 6 in 64bit
and my mbp i7 in 64bit startup-mode, too.

didnt have any freezes since days (or weeks)
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 15:58.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.