On Wed, Apr 29, 2015 at 12:06:42AM +0100, Nicholas Marriott wrote:
> Actually I think I already fixed this?
Yes, I think you rolled this into a larger fix for something else. It
doesn't crash for me anymore.
Cheers,
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart
Actually I think I already fixed this?
On Tue, Apr 28, 2015 at 04:58:51PM +0100, Thomas Adam wrote:
> When checking a client's tty path, don't segfault if it's NULL.
> ---
> cmd-find.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/cmd-find.c b/cm
I don't think we should enter this function at all in that case, or perhaps
just not do the loop
Original message
From: Thomas Adam
Date:28/04/2015 16:58 (GMT+00:00)
To: tmux-users@lists.sourceforge.net
Cc: Thomas Adam
Subject: [PATCH] Don't segfault on NUL
When checking a client's tty path, don't segfault if it's NULL.
---
cmd-find.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmd-find.c b/cmd-find.c
index fab3849..3ac9936 100644
--- a/cmd-find.c
+++ b/cmd-find.c
@@ -243,6 +243,8 @@ cmd_find_current_session_wit
On Sat, Mar 14, 2015 at 11:01:25PM +0530, Anhad Jai Singh wrote:
> Hello,
>
> Earlier today I noticed that tmux had crashed for me, resulting in me
> losing all my existing sessions.
>
> I checked /var/log/messages to find that tmux had segfault-ed over night.
> I was told t
applied, thanks
On Sat, Mar 01, 2014 at 09:54:03AM +, Thomas Adam wrote:
> Don't segfaut when the parent of the layout cell is NULL; also assign the
> lc->parent component to a common variable and use that throughout this
> function.
> ---
> window.c | 9 ++---
> 1 file changed, 6 inse
Don't segfaut when the parent of the layout cell is NULL; also assign the
lc->parent component to a common variable and use that throughout this
function.
---
window.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/window.c b/window.c
index 1dd70c4..f25f64e 100644
---
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
Hi all,
I can reproducibly crash tmux by doing "tmux info".
Debugging information follows. Please let me know if I can provide
anything else useful. tmux is compiled with debugging symbols.
When replying please CC me as I may not see your reply otherwise.
%uname -a
FreeBSD gravity.local 11.0-
Hi,
On 5 September 2012 11:04, Nicholas Marriott
wrote:
> This looks wrong - the first item now has index (u_int)-1?
Yeah -- wasn't thinking properly.
-- Thomas Adam
--
Live Security Virtual Conference
Exclusive live e
rote:
> Even though we skip empty entries separated with commas when we're looking
> at each item, an input such as:
>
> choose-list -l ,,
>
> would still mean we go on to display a blank line, resulting in a segfault
> as there's no data associated with
Even though we skip empty entries separated with commas when we're looking
at each item, an input such as:
choose-list -l ,,
would still mean we go on to display a blank line, resulting in a segfault
as there's no data associated with that entry.
---
cmd-choose-l
C) tmux -v new -s SESSION_3
>4. Resize terminal C to be smaller than the other terminals (will not
>segfault without doing this step)
>5. (D) tmux -v attach -t SESSION_3
>6. (D) C-b :
>7. (D) link-window -s SESSION_2:0
>8. (D) C-b n
>9. (C) C-d (
Did you reproduce this with the latest SVN? Same backtrace?
On Mon, Aug 29, 2011 at 09:50:59PM -0400, Peter John Hartman wrote:
> > What external commands are in your status-{left,right}?
>
> set-option -g status-left
> "#[default,bold]#(tmux-mail)#[default,dim]#(tmux-date)#[default,bold]#(tmux
> What external commands are in your status-{left,right}?
set-option -g status-left
"#[default,bold]#(tmux-mail)#[default,dim]#(tmux-date)#[default,bold]#(tmux-bat)"
set-option -g status-right "#100T #(tmux-disk)#(tmux-wifi)#(tmux-mpc)"
I've attached the scripts below, but I haven't changed anyt
On Mon, Aug 29, 2011 at 09:23:31PM -0400, Peter John Hartman wrote:
> Nothing fancy. I hit Ctl-D to close out a shell session and it segfaulted.
>
> Here's a bt:
>
> Core was generated by `/usr/local/bin/tmux -Lmain -qf
> /home/peterjh/.tmux.init.conf start'.
> Program terminated with signal 11
Nothing fancy. I hit Ctl-D to close out a shell session and it segfaulted.
Here's a bt:
Core was generated by `/usr/local/bin/tmux -Lmain -qf
/home/peterjh/.tmux.init.conf start'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7713d10 in ?? () from /lib/libc.so.6
(gdb) bt
#0 0xb
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
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
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, is a gdb of
tmux vs. core:
Core was generated by `/usr/local/bin
46 matches
Mail list logo
