tcl & tk ports on FreeBSD 10 amd64

Gary Jennejohn gljennjohn at gmail.com
Wed Dec 4 18:02:44 UTC 2013


On Tue, 03 Dec 2013 21:32:56 -0800
Cy Schubert <Cy.Schubert at komquats.com> wrote:

> Hi,
> 
> Sorry for cross posting but this concerns both lists.
> 
> Over the last month or so I've been upgrading my prod infrastructure from 9 
> to 10. It's mostly complete except for a number of issues. One issue, just 
> solved today (circumvented is a better word), is exmh crashing 10.0 on 
> amd64 while on i386 there are no issues with exmh.
> 
> It appears that the tcl and tk ports (all three of them, 8.4, 8.5, and 8.6) 
> will panic 10.0 on amd64 (but not i386) when the ports are built with 
> threading support.
> 
> I haven't had a chance to look at the dump yet but I had a hunch to test 
> the ports without threading support enabled, making the panic go away. If I 
> don't get to it in time, here is what I haveFatal trap 9: general 
> protection fault while in kernel mode
> cpuid = 2; apic id = 02
> instruction pointer     = 0x20:0xffffffff80957aeb
> stack pointer           = 0x28:0xfffffe00f17f9980
> frame pointer           = 0x28:0xfffffe00f17f99a0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 11 (idle: cpu2)
> trap number             = 9
> timeout stopping cpus
> panic: general protection fault
> cpuid = 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> 0xfffffe00f17f9510
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00f17f95c0
> panic() at panic+0x153/frame 0xfffffe00f17f9640
> trap_fatal() at trap_fatal+0x3a2/frame 0xfffffe00f17f96a0
> trap() at trap+0x7bf/frame 0xfffffe00f17f98c0
> calltrap() at calltrap+0x8/frame 0xfffffe00f17f98c0
> --- trap 0x9, rip = 0xffffffff80957aeb, rsp = 0xfffffe00f17f9980, rbp = 
> 0xfffffe
> 00f17f99a0 ---
> cpu_idle_hlt() at cpu_idle_hlt+0x2b/frame 0xfffffe00f17f99a0
> cpu_idle() at cpu_idle+0x93/frame 0xfffffe00f17f99c0
> sched_idletd() at sched_idletd+0x1ee/frame 0xfffffe00f17f9a70
> fork_exit() at fork_exit+0x9a/frame 0xfffffe00f17f9ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00f17f9ab0
> --- trap 0, rip = 0, rsp = 0xfffffe00f17f9b70, rbp = 0 ---
> Uptime: 4m42s
> Dumping 522 out of 5932 MB:..4%..13%..22%..31%..43%..53%..62%..71%..83%..92%
>  so far,
> 
> Tcl/tk are tickling some bug somewhere.
> 
> Before anyone suggests memory, I've been able to reproduce this on an Intel 
> Core i3 machine with 6 GB and an AMD X2 5000+, also with 6 GB, both in 
> amd64 mode. Both systems are dual (or multi) boot. The bug does not exhibit 
> itself in i386 mode. It also doesn't exhibit itself when tcl/tk are built 
> without thread support.
> 
> The only application I know of which tickles the bug is mail/exmh2 (I'm the 
> maintainer) when using a threaded tcl/tk.
> 
> My 11-CURRENT partition on my laptop is still i386 so I haven't been able 
> to reproduce it under 11 with amd64.
> 

I used to use exmh all the time but then I started having problems
with it so I switched to claws-mail.

Anyway, I just installed exmh2 with threaded tcl/tk on

FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #9 r258676: Wed Nov 27
09:57:24 CET 2013 amd64

CPU is a AMD Phenom(tm) II X6 1090T with 8GB of memory.

Didn't have any crashes doing some cursory tests - mostly reading
some e-mails downloaded with getmail.  Didn't try editing or
sending any mails.

-- 
Gary Jennejohn


More information about the freebsd-ports mailing list