The fix works for me !
Thank you
On Fri, Apr 11, 2014 at 9:10 PM, Nicholas Marriott
wrote:
> It doesn't crash for me, but this does:
>
> tmux setb $(perl -e "print \"x\"x1042")
>
> Please try this fix (also fixes some other similar things):
>
>
> diff --git a/arguments.c b/arguments.c
> index d4e
I can still reproduce on tmux from git.
Here is the gdb backtrace (once with 'bt full') from the core dump.
Best regards,
Julien
On Fri, Apr 11, 2014 at 4:40 PM, Nicholas Marriott
wrote:
> Hi
>
> tmux doesn't crash for me, please try to build tmux from git and see if
> you can still reproduce.
This problem disappeared when I switched from Ubuntu to Arch (and therefore
latest versions of everything).
Sorry I can't give more specifics, but I guess it won't be a problem in the
future anyway.
Cheers,
Chris
On Mon, Nov 18, 2013 at 7:36 PM, Nicholas Marriott <
nicholas.marri...@gmail.com>
On 2014-04-14 11:57 +1200, Jan Larres wrote:
> I usually hit the problem when my machine becomes unresponsive for a
> while due to heavy swapping when starting a memory-heavy process. I'm
> not sure if that could cause fork() to fail, but it sounds like a
> possibility.
Yeah. If you have large amo
i have fixed this leak, cheers
On Sat, Apr 12, 2014 at 09:49:17PM +0100, Balazs Kezes wrote:
> On 2014-04-07 13:54 +0200, Pavlos Parissis wrote:
> > Let me know what I else I can do in order to help troubleshooting
> > this.
>
> So I've skimmed the source again and now I've found an actual leak
On 15/04/14 08:14, Balazs Kezes wrote:
> On 2014-04-14 11:57 +1200, Jan Larres wrote:
>> I usually hit the problem when my machine becomes unresponsive for a
>> while due to heavy swapping when starting a memory-heavy process. I'm
>> not sure if that could cause fork() to fail, but it sounds like a
On 15/04/14 10:28, Nicholas Marriott wrote:
> i have fixed this leak, cheers
Great, thank you!
-Jan
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases
Hi
Looks good, but I think we should take PATH from the session or global
environment if a suitable client is not around. Modified diff below.
Not certain about using the cmdq client PATH rather than always
session... although it feels better so I guess go with it.
Problem is no clear rules for
Hi Thomas,
On 2014-04-13 18:55, Thomas Adam wrote:
> ./configure --enable-static
thank you.
Unfortunately that makes certain assumptions. I have now figured it out
after some trial and error. I was using musl-libc, because static
linking would be problematic with glibc.
I'll probably blog about
Hello,
I found a simpler way to reproduce this issue. For instance, this works:
bash$ printf '\ePtmux;\e\e]52;c;%s\a\e\\' "$(cat README | head -c180 |
base64 -w0)"
But if you specify a number larger than 180 to `head -c`, the copy fails:
bash$ printf '\ePtmux;\e\e]52;c;%s\a\e\\' "$(cat README
In cmd-new-session.c, you've made path's type "char *", but everywhere
else it is "const char *". Was that intentional?
The parts of your patch that take the path from the global or session
env seem redundant, unless I'm missing a use case. When a new
session, window, or pane is created, a new e
11 matches
Mail list logo
