Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

monetdb status command crashes under certain conditions #3804

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Closed

monetdb status command crashes under certain conditions #3804

monetdb-team opened this issue Nov 30, 2020 · 0 comments
Labels
bug Something isn't working normal Server Tools

Comments

@monetdb-team
Copy link

Date: 2015-09-03 21:09:12 +0200
From: John Thomas <>
To: Merovingian devs <>
Version: 11.21.5 (Jul2015)

Last updated: 2015-11-03 10:18:45 +0100

Comment 21247

Date: 2015-09-03 21:09:12 +0200
From: John Thomas <>

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36
Build Identifier:

We've been experiencing some intermittent mserver crashes (which I'm investigating and will file a separate bug report for if needed) recently. And it seems that any time one of our databases goes down and is in the middle of restarting, running the command monetdb status <db> results in a monetdb crash with SIGSEGV.

The problem is in the abbreviateString function in tools/merovingian/utils/utils.c, which does not properly handle small desired widths. In this particular case, the width parameter is always 0 (for whatever reason, which I believe to also be a bug), and this results in an attempted memcpy of length 18446744073709551614, which obviously dies a terrible death.

Reproducible: Always

Steps to Reproduce:

  1. Start a database
  2. While the database is still in process of starting up, run monetdb status <db>
  3. Observe crash

Actual Results:

monetdb crashes

Expected Results:

monetdb doesn't crash

Note: This problem was found using Feb2013 SP6 but confirmed to still exist in Jul2015.

Comment 21248

Date: 2015-09-03 22:45:11 +0200
From: @sjoerdmullender

I can't reproduce this problem.
What system are you running this on? Did you compile yourself or are you using a pre-built package?
It looks like you can handle a debugger. What is the stack trace when the crash happens? What is the value of TERMWIDTH (that's a variable, despite the all-caps name).

Comment 21249

Date: 2015-09-03 23:01:13 +0200
From: John Thomas <>

There's a clear logic error in the source:

inline void
abbreviateString(char *ret, const char *in, size_t width)
{
size_t len;
size_t off;

if ((len = strlen(in)) > width) {
/* position abbreviation dots in the middle (Mac style, iso
* Windows style) */
memcpy(ret, in, (width / 2) - 2); // <--- if width < 4, this crashes
memcpy(ret + (width / 2) - 2, "...", 3);
off = len - (width - ((width / 2) - 2) - 3);
memcpy(ret + (width / 2) + 1, in + off, (len - off) + 1);
} else {
sprintf(ret, "%s", in);
}
}

You may have better ideas of how to fix it, but here's the workaround I'm using in my build now:

inline void
abbreviateString(char *ret, const char *in, size_t width)
{
size_t len;
size_t off;

if ((len = strlen(in)) > width) {
if (width >= 4) {
/* position abbreviation dots in the middle (Mac style, iso
* Windows style) */
memcpy(ret, in, (width / 2) - 2);
memcpy(ret + (width / 2) - 2, "...", 3);
off = len - (width - ((width / 2) - 2) - 3);
memcpy(ret + (width / 2) + 1, in + off, (len - off) + 1);
} else {
sprintf(ret, "%.*s", width, in);
}
} else {
sprintf(ret, "%s", in);
}
}

Now as to why in this particular case it is being passed width = 0, I'm not sure. But fixing this function at least keeps it from crashing.

Comment 21250

Date: 2015-09-03 23:05:06 +0200
From: @sjoerdmullender

(In reply to John Thomas from comment 2)

There's a clear logic error in the source:

I understand that. What I was after is where the width=0 comes from.

Comment 21251

Date: 2015-09-03 23:16:08 +0200
From: John Thomas <>

Backtrace (note this was captured from Feb2013 SP6):

(gdb) bt
0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116
1 0x0000000000408abb in memcpy (__len=18446744073709551614, __src=0x7ffc9b18bf10, __dest=0xf2b180) at /usr/include/x86_64-linux-gnu/bits/string3.h:51
2 abbreviateString (ret=0xf2b180 "starting up since 2015-09-03 17", in=0x7ffc9b18bf10 "starting up since 2015-09-03 17", width=0) at utils.c:294
3 0x0000000000405205 in printStatus (uriwidth=0, dbwidth=5, mode=1, stats=0xf2a850) at monetdb.c:333
4 command_status (argv=, argc=) at monetdb.c:855
5 main (argc=, argv=) at monetdb.c:1762

(gdb) p TERMWIDTH
$1 = 0

Another piece of info that might help, the status command is being run via shell out from another program, as opposed a command line prompt. I imagine that's why TERMWIDTH is 0.

Comment 21254

Date: 2015-09-07 15:45:41 +0200
From: MonetDB Mercurial Repository <>

Changeset 23074865b5cf made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=23074865b5cf

Changeset description:

Always use minimum width of 32 for URI in monetdb status command.
This hopefully fixes bug #3804.

Comment 21299

Date: 2015-09-29 14:06:09 +0200
From: @sjoerdmullender

I'm closing this since I believe I fixed this.
If it turns out the bug is still there, please reopen.

Comment 21453

Date: 2015-11-03 10:18:45 +0100
From: @sjoerdmullender

Jul2015 SP1 has been released.

@monetdb-team monetdb-team added bug Something isn't working normal Server Tools labels Nov 30, 2020
@sjoerdmullender sjoerdmullender added this to the Ancient Release milestone Feb 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working normal Server Tools
Projects
None yet
Development

No branches or pull requests

2 participants