Skip to contentSkip to conversation

dlmalloc: ensure gd is set for early alloc

PATCH New Rabin Vincent 3 participants 20 messages Oct 29, 2014 – Nov 10, 2014

lore
Share & tools
lore
#0 lore raw

PATCH 1/6 dlmalloc: ensure gd is set for early alloc

Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized.

Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point.

 $ gdb -q --args ./u-boot
 (gdb) r
 Program received signal SIGSEGV, Segmentation fault.
 0x0000000000412b9b in malloc (bytes=bytes at entry=37) at common/dlmalloc.c:2184
 2184		if (!(gd->flags & GD_FLG_RELOC)) {
 (gdb) p gd
 $1 = (gd_t *) 0x0
 (gdb) bt
 #0  0x0000000000412b9b in malloc (bytes=bytes at entry=37) at common/dlmalloc.c:2184
 #1  0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0)
     at bindtextdom.c:228
 #2  0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350
 #3  __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348
 #4  0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0
 #5  0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc at entry=1, argv=argv at entry=0x7fffffffe208,
     env=env at entry=0x7fffffffe218) at dl-init.c:78
 #6  0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36
 #7  _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126
 #8  0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
---
 common/dlmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
common/dlmalloc.c +1 -1
index f987339..d87834d 100644
@@ -2181,7 +2181,7 @@ Void_t* mALLOc(bytes) size_t bytes;
   INTERNAL_SIZE_T nb;
 
 #ifdef CONFIG_SYS_MALLOC_F_LEN
-	if (!(gd->flags & GD_FLG_RELOC)) {
+	if (gd && !(gd->flags & GD_FLG_RELOC)) {
 		ulong new_ptr;
 		void *ptr;
 
Signature · 1 line
2.1.1
#1 lore raw

PATCH 2/6 sandbox: init cli for -c

sandbox crashes if a variable is set in the -c command, because hush's top_vars is not allocated. Call cli_init() from sandbox to ensure this is done before we execute the -c command.

 $ ./u-boot -c 'a=1'
 ...
 Segmentation fault (core dumped)
---
 arch/sandbox/cpu/start.c | 3 +++
 1 file changed, 3 insertions(+)
arch/sandbox/cpu/start.c +3 -0
index b3d7051..53a99ae 100644
@@ -5,6 +5,7 @@
 
 #include <common.h>
 #include <os.h>
+#include <cli.h>
 #include <asm/getopt.h>
 #include <asm/io.h>
 #include <asm/sections.h>
@@ -76,6 +77,8 @@ int sandbox_main_loop_init(void)
 
 	/* Execute command if required */
 	if (state->cmd) {
+		cli_init();
+
 		run_command_list(state->cmd, -1, 0);
 		if (!state->interactive)
 			os_exit(state->exit_type);
Signature · 1 line
2.1.1
#2 lore raw

PATCH 2/6 sandbox: init cli for -c

Quoted 10 lines · Rabin Vincent

sandbox crashes if a variable is set in the -c command, because hush's top_vars is not allocated. Call cli_init() from sandbox to ensure this is done before we execute the -c command.

 $ ./u-boot -c 'a=1'
 ...
 Segmentation fault (core dumped)
Acked-by Simon Glass <sjg at chromium.org)
#3 lore raw

PATCH 2/6 sandbox: init cli for -c

In reply to Rabin Vincent
Quoted 11 lines · Rabin Vincent

sandbox crashes if a variable is set in the -c command, because hush's top_vars is not allocated. Call cli_init() from sandbox to ensure this is done before we execute the -c command.

 $ ./u-boot -c 'a=1'
 ...
 Segmentation fault (core dumped)

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141110/42776ac9/attachment.pgp>
#4 lore raw

PATCH 3/6 hush: return consistent codes from run_command()

In reply to Rabin Vincent

Attempting to run:
- an empty string
- a string with just spaces

returns different error codes, 1 for the empty string and 0 for the string with just spaces. Make both of them return 0 for consistency.

---
 common/cli_hush.c | 4 +++-
 test/command_ut.c | 3 +++
 2 files changed, 6 insertions(+), 1 deletion(-)
common/cli_hush.c +3 -1
index 2b654b7..9607e93 100644
@@ -3236,8 +3236,10 @@ int parse_string_outer(const char *s, int flag)
 #ifdef __U_BOOT__
 	char *p = NULL;
 	int rcode;
-	if ( !s || !*s)
+	if (!s)
 		return 1;
+	if (!*s)
+		return 0;
 	if (!(p = strchr(s, '\n')) || *++p) {
 		p = xmalloc(strlen(s) + 2);
 		strcpy(p, s);
test/command_ut.c +3 -0
index e136075..a4f0341 100644
@@ -188,6 +188,9 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 #endif
 #endif
 
+	assert(run_command("", 0) == 0);
+	assert(run_command(" ", 0) == 0);
+
 	printf("%s: Everything went swimmingly\n", __func__);
 	return 0;
 }
Signature · 1 line
2.1.1
#6 lore raw

PATCH 3/6 hush: return consistent codes from run_command()

In reply to Rabin Vincent
Quoted 10 lines · Rabin Vincent

Attempting to run:
- an empty string
- a string with just spaces

returns different error codes, 1 for the empty string and 0 for the string with just spaces. Make both of them return 0 for consistency.

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141110/0aaf154c/attachment.pgp>
#7 lore raw

PATCH 4/6 hush: fix segfault on syntax error

In reply to Rabin Vincent

Hush segfaults if it sees a syntax error while attempting to parse a command:

 $ ./u-boot -c "'"
 ...
 syntax error
 Segmentation fault (core dumped)

This is due to a NULL pointer dereference of in_str->p in static_peek(). The problem is that the exit condition for the loop in parse_stream_outer() checks for rcode not being -1, but rcode is only ever 0 or 1.

---
 common/cli_hush.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
common/cli_hush.c +1 -1
index 9607e93..a07ae71 100644
@@ -3217,7 +3217,7 @@ static int parse_stream_outer(struct in_str *inp, int flag)
 		}
 		b_free(&temp);
 	/* loop on syntax errors, return on EOF */
-	} while (rcode != -1 && !(flag & FLAG_EXIT_FROM_LOOP) &&
+	} while (rcode != 1 && !(flag & FLAG_EXIT_FROM_LOOP) &&
 		(inp->peek != static_peek || b_peek(inp)));
 #ifndef __U_BOOT__
 	return 0;
Signature · 1 line
2.1.1
#8 lore raw

PATCH 4/6 hush: fix segfault on syntax error

Hi Rabin,

Quoted 8 lines · Rabin Vincent

Hush segfaults if it sees a syntax error while attempting to parse a command:

 $ ./u-boot -c "'"
 ...
 syntax error
 Segmentation fault (core dumped)
Quoted 6 lines

This is due to a NULL pointer dereference of in_str->p in static_peek(). The problem is that the exit condition for the loop in parse_stream_outer() checks for rcode not being -1, but rcode is only ever 0 or 1.

Acked-by Simon Glass <sjg at chromium.org)

BTW I notice that I still get a crash with

./u-boot -c "''"

Regards,
Simon

#9 lore raw

PATCH 4/6 hush: fix segfault on syntax error

In reply to Rabin Vincent
Quoted 8 lines · Rabin Vincent

Hush segfaults if it sees a syntax error while attempting to parse a command:

 $ ./u-boot -c "'"
 ...
 syntax error
 Segmentation fault (core dumped)
Quoted 8 lines

This is due to a NULL pointer dereference of in_str->p in static_peek(). The problem is that the exit condition for the loop in parse_stream_outer() checks for rcode not being -1, but rcode is only ever 0 or 1.

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141110/0755416d/attachment.pgp>
#10 lore raw

PATCH 5/6 hush: make run_command() return an error on parsing failure

In reply to Rabin Vincent

run_command() returns success even if the command had a syntax error; correct this behaviour.

---
 common/cli_hush.c | 2 +-
 test/command_ut.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
common/cli_hush.c +1 -1
index a07ae71..d643912 100644
@@ -3162,7 +3162,7 @@ static int parse_stream_outer(struct in_str *inp, int flag)
 	o_string temp=NULL_O_STRING;
 	int rcode;
 #ifdef __U_BOOT__
-	int code = 0;
+	int code = 1;
 #endif
 	do {
 		ctx.type = flag;
test/command_ut.c +2 -0
index a4f0341..926573a 100644
@@ -191,6 +191,8 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 	assert(run_command("", 0) == 0);
 	assert(run_command(" ", 0) == 0);
 
+	assert(run_command("'", 0) == 1);
+
 	printf("%s: Everything went swimmingly\n", __func__);
 	return 0;
 }
Signature · 1 line
2.1.1
#12 lore raw

PATCH 5/6 hush: make run_command() return an error on parsing failure

In reply to Rabin Vincent
Quoted 5 lines · Rabin Vincent

run_command() returns success even if the command had a syntax error; correct this behaviour.

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141110/22277735/attachment.pgp>
#13 lore raw

PATCH 6/6 hush: add some tests for quoting

In reply to Rabin Vincent

Add a couple of tests for quoting. The indirect variable read test is a fixed version of the following expression from Fedora ARM's boot.scr. This unfixed expression stopped working after fe9ca3d ("hush: fix some quoted variable expansion issues"):

setenv catcat setenv catout\;'setenv catX "setenv catout '\\\\\\\''\$\$catin'\\\\\\\''"' \; run catX

---
 test/command_ut.c | 10 ++++++++++
 1 file changed, 10 insertions(+)
test/command_ut.c +10 -0
index 926573a..21804a4 100644
@@ -193,6 +193,16 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 
 	assert(run_command("'", 0) == 1);
 
+	assert(run_command("setenv ut_var '\"'; setenv ut_var2 \"${ut_var}\"", 0) == 0);
+	assert(!strcmp(getenv("ut_var2"), "\""));
+
+	assert(run_command("setenv ut_catcat setenv ut_catout\\;setenv ut_catX setenv ut_catout \\\\\\\\\\\\\\\"\\$\\$ut_catin\\\\\\\\\\\\\\\" \\; run ut_catX", 0) == 0);
+	assert(run_command("setenv ut_pointer '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'", 0) == 0);
+	assert(run_command("setenv ut_catin ut_pointer", 0) == 0);
+	assert(run_command("run ut_catcat", 0) == 0);
+	assert(getenv("ut_catout"));
+	assert(!strcmp(getenv("ut_catout"), "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20"));
+
 	printf("%s: Everything went swimmingly\n", __func__);
 	return 0;
 }
Signature · 1 line
2.1.1
#14 lore raw

PATCH 6/6 hush: add some tests for quoting

Hi Rabin,

Quoted 17 lines · Rabin Vincent

Add a couple of tests for quoting. The indirect variable read test is a fixed version of the following expression from Fedora ARM's boot.scr. This unfixed expression stopped working after fe9ca3d ("hush: fix some quoted variable expansion issues"):

setenv catcat setenv catout\;'setenv catX "setenv catout '\\\\\\\''\$\$catin'\\\\\\\''"' \; run catX

---
 test/command_ut.c | 10 ++++++++++
 1 file changed, 10 insertions(+)
test/command_ut.c +0 -0
index 926573a..21804a4 100644

test/command_ut.c static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 200

Quoted 8 lines
test/command_ut.c +5 -0
@@ -193,6 +193,16 @@ static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 
        assert(run_command("'", 0) == 1);
 
+       assert(run_command("setenv ut_var '\"'; setenv ut_var2 \"${ut_var}\"", 0) == 0);
+       assert(!strcmp(getenv("ut_var2"), "\""));
+
+       assert(run_command("setenv ut_catcat setenv ut_catout\\;setenv ut_catX setenv ut_catout \\\\\\\\\\\\\\\"\\$\\$ut_catin\\\\\\\\\\\\\\\" \\; run ut_catX", 0) == 0);
+       assert(run_command("setenv ut_pointer '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'", 0) == 0);

Can we reduce this down to 3-4 numbers for easier maintenance? Or do the 20 numbers buy us something?

Also did you test this with the simple cli parser too?

Quoted 11 lines
test/command_ut.c +5 -1
+       assert(run_command("setenv ut_catin ut_pointer", 0) == 0);
+       assert(run_command("run ut_catcat", 0) == 0);
+       assert(getenv("ut_catout"));
+       assert(!strcmp(getenv("ut_catout"), "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20"));
+
        printf("%s: Everything went swimmingly\n", __func__);
        return 0;
 }
--

2.1.1

Regards,
Simon

#15 lore raw

PATCH 6/6 hush: add some tests for quoting

Quoted 9 lines · Simon Glass

test/command_ut.c static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 200

Quoted 5 lines · Rabin Vincent
test/command_ut.c +5 -0
+       assert(run_command("setenv ut_var '\"'; setenv ut_var2 \"${ut_var}\"", 0) == 0);
+       assert(!strcmp(getenv("ut_var2"), "\""));
+
+       assert(run_command("setenv ut_catcat setenv ut_catout\\;setenv ut_catX setenv ut_catout \\\\\\\\\\\\\\\"\\$\\$ut_catin\\\\\\\\\\\\\\\" \\; run ut_catX", 0) == 0);
+       assert(run_command("setenv ut_pointer '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'", 0) == 0);

Can we reduce this down to 3-4 numbers for easier maintenance? Or do the 20 numbers buy us something?

After 14 arguments, the quotes around them become necessary, so having more than 14 ensures we test that the quotes are still there:

=> setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13
=> setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 14
=> setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
setenv - set environment variables

Usage:
setenv [-f] name value ...
- [forcibly] set environment variable 'name' to 'value ...' setenv [-f] name
- [forcibly] delete environment variable 'name'
=> setenv x '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15'
=>

Quoted 1 line

Also did you test this with the simple cli parser too?

No, I didn't realize that these tests they would get run without hush. I tried them out and they fail with the simple parser, as do the tests with the empty strings in the third patch. What do you suggest? Drop these new tests, or move them inside the ifdef HUSH?

#16 lore raw

PATCH 6/6 hush: add some tests for quoting

Hi,

Quoted 11 lines · Rabin Vincent
Quoted 9 lines · Simon Glass

test/command_ut.c static int do_ut_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 200

Quoted 5 lines · Rabin Vincent
test/command_ut.c +5 -0
+       assert(run_command("setenv ut_var '\"'; setenv ut_var2 \"${ut_var}\"", 0) == 0);
+       assert(!strcmp(getenv("ut_var2"), "\""));
+
+       assert(run_command("setenv ut_catcat setenv ut_catout\\;setenv ut_catX setenv ut_catout \\\\\\\\\\\\\\\"\\$\\$ut_catin\\\\\\\\\\\\\\\" \\; run ut_catX", 0) == 0);
+       assert(run_command("setenv ut_pointer '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20'", 0) == 0);

Can we reduce this down to 3-4 numbers for easier maintenance? Or do the 20 numbers buy us something?

Quoted 7 lines

After 14 arguments, the quotes around them become necessary, so having more than 14 ensures we test that the quotes are still there:

=> setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13
=> setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 14
=> setenv x 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
setenv - set environment variables

OK sounds good. How about adding a test that CONFIG_SYS_MAXARGS is < you number.

Like

#if CONFIG_SYS_MAXARGS > 15
#error "..."
#endif

Otherwise if someone changes it in sandbox the test will change.

Quoted 9 lines

Usage:
setenv [-f] name value ...
- [forcibly] set environment variable 'name' to 'value ...' setenv [-f] name
- [forcibly] delete environment variable 'name'
=> setenv x '1 2 3 4 5 6 7 8 9 10 11 12 13 14 15'
=>

Quoted 6 lines
Quoted 1 line

Also did you test this with the simple cli parser too?

No, I didn't realize that these tests they would get run without hush. I tried them out and they fail with the simple parser, as do the tests with the empty strings in the third patch. What do you suggest? Drop these new tests, or move them inside the ifdef HUSH?

#ifdef HUSH if the tests can't work without it.

Regards,
Simon

#17 lore raw

PATCH 1/6 dlmalloc: ensure gd is set for early alloc

In reply to Rabin Vincent

Hi Rabin,

Quoted 28 lines · Rabin Vincent

Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized.

Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point.

 $ gdb -q --args ./u-boot
 (gdb) r
 Program received signal SIGSEGV, Segmentation fault.
 0x0000000000412b9b in malloc (bytes=bytes at entry=37) at common/dlmalloc.c:2184
 2184           if (!(gd->flags & GD_FLG_RELOC)) {
 (gdb) p gd
 $1 = (gd_t *) 0x0
 (gdb) bt
 #0  0x0000000000412b9b in malloc (bytes=bytes at entry=37) at common/dlmalloc.c:2184
 #1  0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0)
     at bindtextdom.c:228
 #2  0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350
 #3  __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348
 #4  0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0
 #5  0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc at entry=1, argv=argv at entry=0x7fffffffe208,
     env=env at entry=0x7fffffffe218) at dl-init.c:78
 #6  0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36
 #7  _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126
 #8  0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Quoted 1 line

How do you provoke this error? It doesn't seem to happen for me.

Regards,
Simon

#18 lore raw

PATCH 1/6 dlmalloc: ensure gd is set for early alloc

Quoted 28 lines · Simon Glass
Quoted 18 lines · Rabin Vincent

Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized.

Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point.

 $ gdb -q --args ./u-boot
 (gdb) r
 Program received signal SIGSEGV, Segmentation fault.
 0x0000000000412b9b in malloc (bytes=bytes at entry=37) at common/dlmalloc.c:2184
 2184           if (!(gd->flags & GD_FLG_RELOC)) {
 (gdb) p gd
 $1 = (gd_t *) 0x0
 (gdb) bt
 #0  0x0000000000412b9b in malloc (bytes=bytes at entry=37) at common/dlmalloc.c:2184
 #1  0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0)
     at bindtextdom.c:228
Quoted 8 lines
 #2  0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350
 #3  __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348
 #4  0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0
 #5  0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc at entry=1, argv=argv at entry=0x7fffffffe208,
     env=env at entry=0x7fffffffe218) at dl-init.c:78
 #6  0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36
 #7  _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126
 #8  0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Quoted 1 line

How do you provoke this error? It doesn't seem to happen for me.

I just run the u-boot binary, which I built with sandbox_defconfig. Perhaps you have different library versions on your system? (I see it's libgpg-error.so which is triggering the malloc() here.) I run Debian unstable.

#19 lore raw

PATCH 1/6 dlmalloc: ensure gd is set for early alloc

In reply to Rabin Vincent
Quoted 27 lines · Rabin Vincent

Attempting to run the sandbox leads to a segfault, because some dynamic libraries (outside of u-boot) attempt to use malloc() to allocate memory before u-boot's gd variable is initialized.

Check for gd not being NULL in the SYS_MALLOC_F_LEN handling, so that malloc() doesn't crash when called at this point.

 $ gdb -q --args ./u-boot
 (gdb) r
 Program received signal SIGSEGV, Segmentation fault.
 0x0000000000412b9b in malloc (bytes=bytes at entry=37) at common/dlmalloc.c:2184
 2184		if (!(gd->flags & GD_FLG_RELOC)) {
 (gdb) p gd
 $1 = (gd_t *) 0x0
 (gdb) bt
 #0  0x0000000000412b9b in malloc (bytes=bytes at entry=37) at common/dlmalloc.c:2184
 #1  0x00007ffff75bf8e1 in set_binding_values (domainname=0x7ffff11f4f12 "libgpg-error", dirnamep=0x7fffffffe168, codesetp=0x0)
     at bindtextdom.c:228
 #2  0x00007ffff75bfb4c in set_binding_values (codesetp=0x0, dirnamep=0x7fffffffe168, domainname=<optimized out>) at bindtextdom.c:350
 #3  __bindtextdomain (domainname=<optimized out>, dirname=0x7ffff11f4f00 "/usr/share/locale") at bindtextdom.c:348
 #4  0x00007ffff11eca17 in ?? () from /lib/x86_64-linux-gnu/libgpg-error.so.0
 #5  0x00007ffff7dea9fa in call_init (l=<optimized out>, argc=argc at entry=1, argv=argv at entry=0x7fffffffe208,
     env=env at entry=0x7fffffffe218) at dl-init.c:78
 #6  0x00007ffff7deaae3 in call_init (env=0x7fffffffe218, argv=0x7fffffffe208, argc=1, l=<optimized out>) at dl-init.c:36
 #7  _dl_init (main_map=0x7ffff7ffe1a8, argc=1, argv=0x7fffffffe208, env=0x7fffffffe218) at dl-init.c:126
 #8  0x00007ffff7ddd1ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Quoted 2 lines

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141110/72127b2f/attachment.pgp>