Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl
@ 2020-10-11 19:29 duncancmt
  2020-10-11 19:46 ` ericonr
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: duncancmt @ 2020-10-11 19:29 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

New issue by duncancmt on void-packages repository

https://github.com/void-linux/void-packages/issues/25531

Description:
Yet another report in my "PACKAGE segfaults on aarch64-musl" series. See also #24783 #24785 #24918 and #25125 (more to come, I'm sure).

### System

* xuname:  
  *Void 5.7.0_1 aarch64-musl Unknown uptodate rrFFFFF*
* package:  
  *mlocate-0.26_4*

### Expected behavior

```
# mupdatedb -f proc
# echo $?
0
```

### Actual behavior

```
# mupdatedb -f proc
Segmentation fault
```

### Steps to reproduce the behavior

See above

### Other remarks

```
# mupdate
# echo $?
0
```

Omitting the `-f proc` flag fixes the problem. I regret that I cannot post a traceback here. `gdb` itself suffers from a probably-related segfault (see #24785).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mlocate `mupdatedb -f proc` segfaults on aarch64-musl
  2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
@ 2020-10-11 19:46 ` ericonr
  2020-10-11 19:52 ` duncancmt
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ericonr @ 2020-10-11 19:46 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/25531#issuecomment-706758323

Comment:
Regarding this specific bug, is it straceable?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mlocate `mupdatedb -f proc` segfaults on aarch64-musl
  2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
  2020-10-11 19:46 ` ericonr
@ 2020-10-11 19:52 ` duncancmt
  2020-10-11 20:05 ` ericonr
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: duncancmt @ 2020-10-11 19:52 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

New comment by duncancmt on void-packages repository

https://github.com/void-linux/void-packages/issues/25531#issuecomment-706758933

Comment:
The `strace` doesn't appear to be _super_ helpful, but I'm not totally clear what I'm looking for.

[mupdatedb.log](https://github.com/void-linux/void-packages/files/5361862/mupdatedb.log)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mlocate `mupdatedb -f proc` segfaults on aarch64-musl
  2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
  2020-10-11 19:46 ` ericonr
  2020-10-11 19:52 ` duncancmt
@ 2020-10-11 20:05 ` ericonr
  2020-10-12  1:04 ` duncancmt
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ericonr @ 2020-10-11 20:05 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 186 bytes --]

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/25531#issuecomment-706760593

Comment:
yeah, I can't spot anything weird either :/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mlocate `mupdatedb -f proc` segfaults on aarch64-musl
  2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
                   ` (2 preceding siblings ...)
  2020-10-11 20:05 ` ericonr
@ 2020-10-12  1:04 ` duncancmt
  2020-10-12  1:04 ` [ISSUE] [CLOSED] " duncancmt
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: duncancmt @ 2020-10-12  1:04 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

New comment by duncancmt on void-packages repository

https://github.com/void-linux/void-packages/issues/25531#issuecomment-706802323

Comment:
duplicates #25535

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ISSUE] [CLOSED] mlocate `mupdatedb -f proc` segfaults on aarch64-musl
  2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
                   ` (3 preceding siblings ...)
  2020-10-12  1:04 ` duncancmt
@ 2020-10-12  1:04 ` duncancmt
  2020-10-20 19:53 ` duncancmt
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: duncancmt @ 2020-10-12  1:04 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Closed issue by duncancmt on void-packages repository

https://github.com/void-linux/void-packages/issues/25531

Description:
Yet another report in my "PACKAGE segfaults on aarch64-musl" series. See also #24783 #24785 #24918 and #25125 (more to come, I'm sure).

### System

* xuname:  
  *Void 5.7.0_1 aarch64-musl Unknown uptodate rrFFFFF*
* package:  
  *mlocate-0.26_4*

### Expected behavior

```
# mupdatedb -f proc
# echo $?
0
```

### Actual behavior

```
# mupdatedb -f proc
Segmentation fault
```

### Steps to reproduce the behavior

See above

### Other remarks

```
# mupdate
# echo $?
0
```

Omitting the `-f proc` flag fixes the problem. I regret that I cannot post a traceback here. `gdb` itself suffers from a probably-related segfault (see #24785).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mlocate `mupdatedb -f proc` segfaults on aarch64-musl
  2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
                   ` (4 preceding siblings ...)
  2020-10-12  1:04 ` [ISSUE] [CLOSED] " duncancmt
@ 2020-10-20 19:53 ` duncancmt
  2020-10-26 15:28 ` sgn
  2020-10-26 15:43 ` [ISSUE] [CLOSED] " sgn
  7 siblings, 0 replies; 9+ messages in thread
From: duncancmt @ 2020-10-20 19:53 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

New comment by duncancmt on void-packages repository

https://github.com/void-linux/void-packages/issues/25531#issuecomment-713101307

Comment:
I'm re-opening this issue because #25605 did not fix the segfault here. Fortunately, it *did* fix `gdb`, so now I have a backtrace
```
# gdb --args `which mupdatedb` -f proc
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /bin/mupdatedb...
Reading symbols from /usr/lib/debug//usr/bin/mupdatedb...
(gdb) run
Starting program: /usr/bin/mupdatedb -f proc

Program received signal SIGSEGV, Segmentation fault.
0x0000fffff7fa4440 in strcmp (l=0xfffff7ffb5c0 "/boot",
    r=0xffffffffaaace020 <error: Cannot access memory at address 0xffffffffaaace020>) at src/string/strcmp.c:5
5       src/string/strcmp.c: No such file or directory.
(gdb) bt
#0  0x0000fffff7fa4440 in strcmp (l=0xfffff7ffb5c0 "/boot",
    r=0xffffffffaaace020 <error: Cannot access memory at address 0xffffffffaaace020>) at src/string/strcmp.c:5
#1  0x0000aaaaaaaaea94 in filesystem_is_excluded (path=0xfffff7ffb5c0 "/boot") at src/updatedb.c:404
#2  scan (path=0xfffff7ffb5c0 "/boot", cwd_fd=0xfffffffff178, relative=0xaaaaaaacc229 "boot", st_parent=<optimized out>)
    at src/updatedb.c:765
#3  0x0000aaaaaaaaf1d0 in scan_subdirs (st=0xfffffffff180, dir=<synthetic pointer>) at src/updatedb.c:497
#4  scan (path=<optimized out>, cwd_fd=0xfffffffff328, relative=<optimized out>, st_parent=<optimized out>) at src/updatedb.c:825
#5  0x0000aaaaaaaac778 in main (argc=<optimized out>, argv=<optimized out>) at src/updatedb.c:1012
```

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: mlocate `mupdatedb -f proc` segfaults on aarch64-musl
  2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
                   ` (5 preceding siblings ...)
  2020-10-20 19:53 ` duncancmt
@ 2020-10-26 15:28 ` sgn
  2020-10-26 15:43 ` [ISSUE] [CLOSED] " sgn
  7 siblings, 0 replies; 9+ messages in thread
From: sgn @ 2020-10-26 15:28 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/25531#issuecomment-716623954

Comment:
I'm really NOT understand this crash.
On frame #2, gnulib's `canonicalize_file_name` was called, which in turn call `__realpath`, which `malloc` some 4096 bytes, but some how `free`-d afterward, without any trace of `free`. I'll see if patching `canonicalize_file_name` to use musl's `realpath` works?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ISSUE] [CLOSED] mlocate `mupdatedb -f proc` segfaults on aarch64-musl
  2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
                   ` (6 preceding siblings ...)
  2020-10-26 15:28 ` sgn
@ 2020-10-26 15:43 ` sgn
  7 siblings, 0 replies; 9+ messages in thread
From: sgn @ 2020-10-26 15:43 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Closed issue by duncancmt on void-packages repository

https://github.com/void-linux/void-packages/issues/25531

Description:
Yet another report in my "PACKAGE segfaults on aarch64-musl" series. See also #24783 #24785 #24918 and #25125 (more to come, I'm sure).

### System

* xuname:  
  *Void 5.7.0_1 aarch64-musl Unknown uptodate rrFFFFF*
* package:  
  *mlocate-0.26_4*

### Expected behavior

```
# mupdatedb -f proc
# echo $?
0
```

### Actual behavior

```
# mupdatedb -f proc
Segmentation fault
```

### Steps to reproduce the behavior

See above

### Other remarks

```
# mupdate
# echo $?
0
```

Omitting the `-f proc` flag fixes the problem. I regret that I cannot post a traceback here. `gdb` itself suffers from a probably-related segfault (see #24785).

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-10-26 15:43 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-11 19:29 [ISSUE] mlocate `mupdatedb -f proc` segfaults on aarch64-musl duncancmt
2020-10-11 19:46 ` ericonr
2020-10-11 19:52 ` duncancmt
2020-10-11 20:05 ` ericonr
2020-10-12  1:04 ` duncancmt
2020-10-12  1:04 ` [ISSUE] [CLOSED] " duncancmt
2020-10-20 19:53 ` duncancmt
2020-10-26 15:28 ` sgn
2020-10-26 15:43 ` [ISSUE] [CLOSED] " sgn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).