#1401 closed defect (fixed)
jobjc_mapObjects() collision
Reported by: | sassijr | Owned by: | dkocher |
---|---|---|---|
Priority: | high | Milestone: | 2.8.3 |
Component: | core | Version: | 2.8.3 |
Severity: | normal | Keywords: | |
Cc: | Architecture: | ||
Platform: |
Description
Cyberduck quits after uploads start, using Mac OSX Leopard 10.5, it has always worked up till now! Any issues with Leopard? Have most recent version I believe.
thanks
Change History (9)
comment:1 Changed on Dec 10, 2007 at 10:49:42 AM by GREENSKiN
comment:2 Changed on Dec 10, 2007 at 11:10:39 PM by dkocher
Please let me know if running the latest nightly build from http://update.cyberduck.ch/nightly/ does any good.
comment:3 Changed on Dec 13, 2007 at 8:52:53 PM by prpghandi
I just installed the latest nightly (3348) and it's just quitting on me randomly. I can't seem to find any pattern either. Here's my console report.
12/13/07 3:16:05 PM Cyberduck[7010] jobjc_mapObjects() collision, objc object 13fb80 of type (NSCFTimer) being entered for Java object of class (com/apple/cocoa/foundation/NSTimer) in entry 1b2ab240 12/13/07 3:16:05 PM Cyberduck[7010] existing java object's class is (com/apple/cocoa/foundation/NSTimer) 12/13/07 3:16:05 PM Cyberduck[7010] no corresponding java entry! (did it get collected?) 12/13/07 3:16:05 PM [0x0-0x4aa4aa].ch.sudo.cyberduck[7010] ObjCJava FATAL: 12/13/07 3:16:05 PM [0x0-0x4aa4aa].ch.sudo.cyberduck[7010] jobjc_mapObjects(): mapping inconsistency -- hashtable entries are not identical 12/13/07 3:16:05 PM [0x0-0x4aa4aa].ch.sudo.cyberduck[7010] ObjCJava Exit 12/13/07 3:16:05 PM com.apple.launchd[70] ([0x0-0x4aa4aa].ch.sudo.cyberduck[7010]) Exited with exit code: 255
comment:4 Changed on Dec 13, 2007 at 9:15:10 PM by dkocher
- Summary changed from Cyberduck quits, using Mac OSX Leopard 10.5 to jobjc_mapObjects() collision
comment:5 Changed on Dec 17, 2007 at 9:00:31 PM by GREENSKiN
Yes, still happens with the latest nightly (3353). Same console output:
12/17/07 9:52:53 PM Cyberduck[1579] jobjc_mapObjects() collision, objc object 141bb0 of type (NSCFTimer) being entered for Java object of class (com/apple/cocoa/foundation/NSTimer) in entry 1be6a440 12/17/07 9:52:53 PM Cyberduck[1579] existing java object's class is (com/apple/cocoa/foundation/NSTimer) 12/17/07 9:52:53 PM Cyberduck[1579] no corresponding java entry! (did it get collected?) 12/17/07 9:52:53 PM [0x0-0x5e05e].ch.sudo.cyberduck[1579] ObjCJava FATAL: 12/17/07 9:52:53 PM [0x0-0x5e05e].ch.sudo.cyberduck[1579] jobjc_mapObjects(): mapping inconsistency -- hashtable entries are not identical 12/17/07 9:52:53 PM [0x0-0x5e05e].ch.sudo.cyberduck[1579] ObjCJava Exit 12/17/07 9:52:53 PM com.apple.launchd[94] ([0x0-0x5e05e].ch.sudo.cyberduck[1579]) Exited with exit code: 255
comment:6 Changed on Dec 22, 2007 at 6:42:14 AM by damainman
- Version changed from 2.7.3 to 2.8.3
I have the same issue as well using the latest nightly build I installed today and also using leopard. Cyberduck disapeers within minutes if I upload two folders with numerous files simultaneously.
However if i only upload 1 folder at a time, it doesn't disappear. But... after a few minutes of uploading the "transfers" window shows the transfer as being "incomplete" and I need to run the "resume" function to get it to upload again.
Today I was uploading a folder with hundreds of files, and literally needed to run the "resume" feature about 20-30 times. I get no timeout errors, I get no errors at all. The "Transfer" of the folder just changes from "uploading" to "incomplete" with no messages or warnings.
comment:7 Changed on Dec 22, 2007 at 6:45:22 AM by damainman
Forgot to mention I also see similar errors in the console that "Greenskin" posted. And I can make cyberduck disappear on command, just by trying to upload more then 1 folder at time to the same ftp server.
comment:8 Changed on Dec 29, 2007 at 5:55:13 PM by dkocher
- Milestone set to 2.8.3
- Status changed from new to assigned
comment:9 Changed on Dec 29, 2007 at 6:04:06 PM by dkocher
- Resolution set to fixed
- Status changed from assigned to closed
Issues like this should be resolved by a refactored access to non-thread safe method calls in the Cocoa Framework. In r3377.
Same here. Happens semi-randomly. Console reports: