It's ok, the problem is that when NetBSD implemented strnvis they rather
stupidly changed the argument order and FreeBSD picked up the functions
from them. Please give the configure.ac change in my last mail a go.
Thanks
On Mon, Dec 02, 2013 at 07:51:17PM -0500, Eitan Adler wrote:
> On Mon, Dec
On Mon, Dec 2, 2013 at 6:55 PM, Nicholas Marriott
wrote:
> Honestly, you are not making this easy...
I'm sorry... I'm trying to provide what you are asking for; I supplied
*ent previously but will supply it again here.
gdb$ up
#1 0x000800fec57f in ?? () from /lib/libc.so.7
gdb$ up
#2 0x00
try this please, although i'm not sure if this is what i want to do at
least i'll know if it works
you'll need to rerun autogen.sh and then configure
diff --git a/configure.ac b/configure.ac
index ceb37db..644b283 100644
--- a/configure.ac
+++ b/configure.ac
@@ -312,6 +312,16 @@ AM_CONDITIONAL(NO
Never mind, looks like FreeBSD's strnvis argument order is different
from OpenBSD's, looking to see when that happened.
On Mon, Dec 02, 2013 at 11:55:32PM +, Nicholas Marriott wrote:
> Honestly, you are not making this easy...
>
> Could you just do "p *ent" and "p *code" from this frame in
Honestly, you are not making this easy...
Could you just do "p *ent" and "p *code" from this frame in gdb?
With -O0 you should hopefully see something like:
(gdb) p *ent
$1 = {code = TTYC_BEL, type = TTYCODE_STRING, name = 0x3c00cf68 "bel"}
(gdb) p *code
$2 = {type = TTYCODE_STRING, value = {str
On Mon, Dec 2, 2013 at 4:57 PM, Nicholas Marriott
wrote:
> yeah give that a try if you can
gdb$ p/x ent
$1 = 0x478030
gdb$ p/x *ent
$2 = {
code = 0x1,
type = 0x1,
name = 0x4789f0
}
(lldb) thread backtrace
* thread #1: tid = 0, 0x00080104a01b
libc.so.7`strlen(str=0x0050) + 1
yeah give that a try if you can
On Mon, Dec 02, 2013 at 04:52:50PM -0500, Eitan Adler wrote:
> On Mon, Dec 2, 2013 at 10:09 AM, Nicholas Marriott
> wrote:
> > I need to see inside the ent and code structures. Can you use gdb and
> > then do "p *ent" and "p *code" from frame 3? Or whatever frame i
On Mon, Dec 2, 2013 at 10:09 AM, Nicholas Marriott
wrote:
> I need to see inside the ent and code structures. Can you use gdb and
> then do "p *ent" and "p *code" from frame 3? Or whatever frame it shows
> is in cmd_server_info_exec.
gdb says "No symbol "ent" in current context."
lldb says (const
I need to see inside the ent and code structures. Can you use gdb and
then do "p *ent" and "p *code" from frame 3? Or whatever frame it shows
is in cmd_server_info_exec.
On Mon, Dec 02, 2013 at 09:52:19AM -0500, Eitan Adler wrote:
> On Mon, Dec 2, 2013 at 3:52 AM, Nicholas Marriott
> wrote:
> >
On Mon, Dec 2, 2013 at 3:52 AM, Nicholas Marriott
wrote:
> Show me "bt full" from gdb please
gdb761$ bt full
#0 strlen (str=0x50 ) at
/usr/src/lib/libc/string/strlen.c:100
lp =
va =
vb =
p =
#1 0x000800fc657f in istrsenvisx (mbdst=0x7fffafd0 "",
dlen=
Also please go to frame 3 (in cmd_server_info_exec) and show me "p *ent"
and "p *code".
On Sun, Dec 01, 2013 at 11:31:09PM -0500, Eitan Adler wrote:
> Hi all,
>
> I can reproducibly crash tmux by doing "tmux info".
>
> Debugging information follows. Please let me know if I can provide
> anythi
Show me "bt full" from gdb please
Original message
From: Eitan Adler
Date: 02/12/2013 04:31 (GMT+00:00)
To: tmux-users@lists.sourceforge.net
Subject: Segfault when doing "tmux info"
Hi all,
I can reproducibly crash tmux by doing "tmux info".
Debugging information follo
You still get them with the patch I sent?
On Mon, Nov 29, 2010 at 02:45:23PM -0500, Peter John Hartman wrote:
> On Mon, Nov 29, 2010 at 07:35:45PM +, Nicholas Marriott wrote:
> > So I guess this is okay? Guys?
>
> Nope. I still get random crashes of this sort. And I, still, unlike Thomas
>
On Mon, Nov 29, 2010 at 07:35:45PM +, Nicholas Marriott wrote:
> So I guess this is okay? Guys?
Seems to be. I am still getting segfaults though -- will investigate
further, as I can't believe it's anything directly related to the proposed
patch. Regardless, just from a cursive point of view
On Mon, Nov 29, 2010 at 07:35:45PM +, Nicholas Marriott wrote:
> So I guess this is okay? Guys?
Nope. I still get random crashes of this sort. And I, still, unlike Thomas
Adam, haven't been able to find the right combination that reproduces it.
It can't be anything mouse related, as I have
So I guess this is okay? Guys?
On Mon, Nov 22, 2010 at 10:56:50PM +, Nicholas Marriott wrote:
> Are you sure you tried the same thing? I can't make it crash with this
> on Linux.
>
>
>
> On Sun, Nov 21, 2010 at 04:22:27PM +, Thomas Adam wrote:
> > On Sun, Nov 21, 2010 at 04:18:12PM +0
Yes, I know about these but they are more limited. In any case, I can't
reproduce with the window.c fix on either platform.
On Tue, Nov 23, 2010 at 12:40:06AM +, Ben Boeckel wrote:
> Nicholas Marriott wrote:
> > Pretty sure this is use-after-free, which points to w->last still not
> > being
Nicholas Marriott wrote:
> Pretty sure this is use-after-free, which points to w->last still not
> being set properly somewhere.
>
> Can't reproduce on OpenBSD though and its malloc() is much more
> rigorous has much better error checking...
The MALLOC_CHECK_ and MALLOC_PERTERB_ variables make m
Are you sure you tried the same thing? I can't make it crash with this
on Linux.
On Sun, Nov 21, 2010 at 04:22:27PM +, Thomas Adam wrote:
> On Sun, Nov 21, 2010 at 04:18:12PM +, Nicholas Marriott wrote:
> > Does this fix it?
> >
> > Index: window.c
> > ==
Pretty sure this is use-after-free, which points to w->last still not
being set properly somewhere.
Can't reproduce on OpenBSD though and its malloc() is much more
rigorous has much better error checking...
On Sun, Nov 21, 2010 at 04:14:21PM +, Thomas Adam wrote:
> On Sun, Nov 21, 2010 at 03
On Sun, Nov 21, 2010 at 04:18:12PM +, Nicholas Marriott wrote:
> Does this fix it?
>
> Index: window.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/window.c,v
> retrieving revision 1.58
> retrieving revision 1.59
> diff -u -p -r1.58 -r
Hmm, okay. I don't have time to look at this today, i'll try to
reproduce tomorrow
cheers
On Sun, Nov 21, 2010 at 04:22:27PM +, Thomas Adam wrote:
> On Sun, Nov 21, 2010 at 04:18:12PM +, Nicholas Marriott wrote:
> > Does this fix it?
> >
> > Index: window.c
> >
Does this fix it?
Index: window.c
===
RCS file: /cvs/src/usr.bin/tmux/window.c,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -p -r1.58 -r1.59
--- window.c23 Oct 2010 13:04:34 - 1.58
+++ window.c14 Nov 20
On Sun, Nov 21, 2010 at 03:32:08PM +, Nicholas Marriott wrote:
> tmux version?
>
> what platform?
It seems I can always reproduce this -- at least to get a stack trace
identical to the one reported.
This is tmux cvs HEAD (as of today) on Linux (Debian Unstable).
If I start tmux like this:
can you show me the full backtrace and output of "p *wp" and "p *w" from
frame 0?
On Sun, Nov 21, 2010 at 11:02:46AM -0500, Peter John Hartman wrote:
> On Sun, Nov 21, 2010 at 03:32:08PM +, Nicholas Marriott wrote:
> > tmux version?
> >
> > what platform?
>
> VERSION: TMUX 1.4 (last updated
On Sun, Nov 21, 2010 at 03:32:08PM +, Nicholas Marriott wrote:
> tmux version?
>
> what platform?
VERSION: TMUX 1.4 (last updated from cvs 3 days ago, although the problem is
much
older than that)
PLATFORM: Linux
--
sic dicit magister P
PhD Candidate
Collaborative Programme in Ancient and
tmux version?
what platform?
On Sat, Nov 20, 2010 at 10:28:02PM -0500, Peter John Hartman wrote:
> Hi,
>
> I get a segfault about daily, usually when I have a lot of panes open and I
> close one, although, since it is usually in a complex environment, I haven't
> been able to precisely figure
On Sun, Nov 21, 2010 at 10:08:27AM +, Thomas Adam wrote:
> I bet you're using "mouse-select-pane", right? If you disable that, does
> the crash go away?
Nope. Below is my conf.
# generic options
set-option -g base-index 1
setw -g automatic-rename off
set-option -g set-titles off
set-option
On Sat, Nov 20, 2010 at 10:28:02PM -0500, Peter John Hartman wrote:
> Hi,
>
> I get a segfault about daily, usually when I have a lot of panes open and I
> close one, although, since it is usually in a complex environment, I haven't
> been able to precisely figure out what is wrong. Here, however
29 matches
Mail list logo
