Thanks,
G
I have attached a text file which I used for testing. If I copy all of
text from the file and paste in iTerm, it crashes. However, my test
case earlier was that I had an ssh connection to a server which wasn't
local. And there when I pasted, I got those bell sounds and parts of
the text was missing in the file which the copy paste was supposed to
create.
If it means anything, I copied the text from a text editor called
"TextWrangler" which is for free in Mac App Store. The ssh server I
connected to was a Centos 5.6 server and the connection was about
10mbit.
Let me know if you have some further questions.
Cheers,
Hannu
2011/6/6 George Nachman <gnac...@llamas.org>:
Can you reproduce the crash on more than one Mac?
Both computers are a bit older laptops, a 15" Macbook Pro from 2007 &
13,3" Macbook from 2008 with the latest OS X.
I couldn't make it crash anymore after changing some configuration. I
attached a screen shot which shows the attempts of Pasting in two
windows. You can see that the content of those windows is not exactly
the same. Not even close.
Hannu
2011/6/7 George Nachman <gnac...@llamas.org>:
Please send me your ~/Library/Preferences/com.googlecode.iterm2.plist
file in case there's something configuration-specific that's causing
this. I'm really interested in reproducing it, but I've been catting
that file for a while with no effect :(
To be sure that we do it the same way I have the steps here:
1) Open that itermbug.txt in TextEdit or some other text editor.
2) Copy all the text
3) Paste that in a iTerm2 terminal
4) It will create a file mytestfile.txt and it should contain some
errors and should be different almost every time you paste the text in
the terminal.
Is there any other information I could provide?
Hannu
2011/6/8 George Nachman <gnac...@llamas.org>:
Weirdly, it only seems to crash if I paste it directly into the shell;
pasting into vim, nano both seem to handle it fine (for at least 10
pastes in a row). Pasting into the shell crashes it every time.
See below for the crash report (UKCrashReporter seems to be
misbehaving, and
I'm on the wrong branch for fixing it just now :/)
--Tom
On 8 Jun 2011, at 07:04, George Nachman wrote:
> Does it crash when you use the file you attached? Wil running that
> once cause the crash/corruption? How often can you reproduce it?
>
> Please send me your ~/Library/Preferences/com.googlecode.iterm2.plist
> file in case there's something configuration-specific that's causing
> this. I'm really interested in reproducing it, but I've been catting
> that file for a while with no effect :(
Process: iTerm [34344]
Path: /Applications/iTerm.app/Contents/MacOS/iTerm
Identifier: com.googlecode.iterm2
Version: 0.20.20110607 (0.20.20110607)
Code Type: X86-64 (Native)
Parent Process: launchd [160]
Interval Since Last Report: 310 sec
Crashes Since Last Report: 1
Per-App Interval Since Last Report: 248 sec
Per-App Crashes Since Last Report: 1
Date/Time: 2011-06-08 11:05:26.457 +0100
OS Version: Mac OS X 10.5.8 (9L31a)
Report Version: 6
Anonymous UUID: 0DD14239-1E0C-4B6E-9651-E784CA9CE13E
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000118990fff
Crashed Thread: 2
Thread 0:
0 libSystem.B.dylib 0x00007fff83973dd6 mach_msg_trap + 10
1 libSystem.B.dylib 0x00007fff8397b413 mach_msg + 59
2 com.apple.CoreFoundation 0x00007fff82e1e9cf
CFRunLoopRunSpecific + 1631
3 com.apple.HIToolbox 0x00007fff80da4d0e
RunCurrentEventLoopInMode + 278
4 com.apple.HIToolbox 0x00007fff80da4b44
ReceiveNextEventCommon + 322
5 com.apple.HIToolbox 0x00007fff80da49ef
BlockUntilNextEventMatchingListInMode + 79
6 com.apple.AppKit 0x00007fff8405ee70 _DPSNextEvent +
603
7 com.apple.AppKit 0x00007fff8405e7b1 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 136
8 com.apple.AppKit 0x00007fff84058523 -[NSApplication
run] + 434
9 com.apple.AppKit 0x00007fff840252f0
NSApplicationMain + 373
10 com.googlecode.iterm2 0x0000000100001094 start + 52
Thread 1:
0 libSystem.B.dylib 0x00007fff8397ada2 __semwait_signal
+ 10
1 com.apple.Foundation 0x00007fff8080ec4f +[NSThread
sleepForTimeInterval:] + 63
2 com.googlecode.iterm2 0x0000000100039ba4 -[ProcessCache
_run] + 116 (ProcessCache.m:253)
3 com.apple.Foundation 0x00007fff807cad35
__NSThread__main__ + 1157
4 libSystem.B.dylib 0x00007fff839a1e8f _pthread_start +
316
5 libSystem.B.dylib 0x00007fff839a1d51 thread_start + 13
Thread 2 Crashed:
0 libSystem.B.dylib 0x00007fffffe00ea7 __memcpy + 1799
(cpu_capabilities.h:246)
1 com.googlecode.iterm2 0x000000010007df6c -[PTYTask
processWrite] + 220 (PTYTask.m:616)
2 com.googlecode.iterm2 0x000000010007ee90 -[TaskNotifier
run] + 1440 (PTYTask.m:306)
3 com.apple.Foundation 0x00007fff807cad35
__NSThread__main__ + 1157
4 libSystem.B.dylib 0x00007fff839a1e8f _pthread_start +
316
5 libSystem.B.dylib 0x00007fff839a1d51 thread_start + 13
Thread 2 crashed with X86 Thread State (64-bit):
rax: 0x74697720796c6e6f rbx: 0x0000000000023125 rcx:
0x0000000000000001 rdx: 0x0000000000000020
rdi: 0x0000000118991008 rsi: 0x0000000118990fff rbp:
0x0000000118c5f950 rsp: 0x0000000118c5f950
r8: 0x0000000117f0f678 r9: 0x0000000000000000 r10:
0x0000000102980200 r11: 0x0000000118991000
r12: 0x0000000117f0f510 r13: 0xffffffffffffffff r14:
0x0000000118991000 r15: 0x0000000117fe2d80
rip: 0x00007fffffe00ea7 rfl: 0x0000000000010216 cr2:
0x0000000118990fff
Binary Images:
0x100000000 - 0x10011cfef +com.googlecode.iterm2
0.20.20110607 (0.20.20110607) <eb27c3da51f8ddc4594939cb7e922137> /
Applications/iTerm.app/Contents/MacOS/iTerm
0x10020e000 - 0x100217fff +iTerm ??? (???)
<433d9e3780c33d01a263a347ab3872f5> /Applications/iTerm.app/Contents/
Frameworks/iTerm.framework/Versions/A/iTerm
The readline library is GPL, and Apple is generally allergic to that
license. They use NetBSD's "editline" library (libedit.dylib).
I mention this because libedit is FOSS, so you can look at the source.
Last I looked, editline was reasonably compatible with readline,
however, readline still has features that libedit doesn't, so it is
plausible that any app depending on those features might misbehave in
the absence of the _real_ readline. Nevertheless, the compatibility is
sufficient that Apple simply symlinks libreadline -> libedit.
--
Edward Marczak
w: http://www.radiotope.com/writing
Managed Prefs Book: http://goo.gl/8iVmo
MacTech Conference: http://www.mactech.com/conference
Hannu
2011/6/15 George Nachman <gnac...@llamas.org>: