Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • aports aports
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare
  • Issues 638
    • Issues 638
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 322
    • Merge requests 322
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • alpinealpine
  • aportsaports
  • Issues
  • #10896
Closed
Open
Issue created Oct 23, 2019 by bogen85@bogen85

Current edge (and stable) segfault on backtrace from libexecinfo

I'm opening this up due to https://github.com/vlang/v/issues/2508

OS (current edge):

$ uname -a
Linux aplineoct19 4.19.78-1-virt #2-Alpine SMP Wed Oct 9 08:49:48 UTC 2019 x86_64 Linux

$ cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.11_alpha20190925
PRETTY_NAME="Alpine Linux edge"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"

OS (stable):

$ uname -a
Linux osbo 4.19.80-0-virt #1-Alpine SMP Fri Oct 18 11:51:24 UTC 2019 x86_64 Linux

$ cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.10.3
PRETTY_NAME="Alpine Linux v3.10"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"

What did you do? Compiled and and ran the backtrace example from 'man backtrace'

#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define BT_BUF_SIZE 100

void myfunc3(void) {
    int j, nptrs;
    void *buffer[BT_BUF_SIZE];
    char **strings;

    nptrs = backtrace(buffer, BT_BUF_SIZE);
    printf("backtrace() returned %d addresses\n", nptrs);

    /* The call backtrace_symbols_fd(buffer, nptrs, STDOUT_FILENO)
       would produce similar output to the following: */

    strings = backtrace_symbols(buffer, nptrs);
    if (strings == NULL) {
        perror("backtrace_symbols");
        exit(EXIT_FAILURE);
    }

    for (j = 0; j < nptrs; j++)
        printf("%s\n", strings[j]);

    free(strings);
}
static void myfunc2(void) {
    myfunc3();
}

void myfunc(int ncalls) {
    if (ncalls > 1)
        myfunc(ncalls - 1);
    else
        myfunc2();
}

int main(int argc, char *argv[]) {
    if (argc != 2) {
        fprintf(stderr, "%s num-calls\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    myfunc(atoi(argv[1]));
    exit(EXIT_SUCCESS);
}

What did you expect to see?

Something similar to what I get on archlinux:

$ gcc -o bt bt.c
$ ./bt 1
backtrace() returned 6 addresses
./bt(+0x11f7) [0x56461df1a1f7]
./bt(+0x12c9) [0x56461df1a2c9]
./bt(+0x12f1) [0x56461df1a2f1]
./bt(+0x134f) [0x56461df1a34f]
/usr/lib/libc.so.6(__libc_start_main+0xf3) [0x7f84c865c153]
./bt(+0x10fe) [0x56461df1a0fe]

What did you see instead? When I compile and run it I get a segfault:

$ gcc -o bt bt.c -lexecinfo
$ ./bt 1
Segmentation fault

What line from the backtrace example code is segfaulting?

    char **strings;

    nptrs = backtrace(buffer, BT_BUF_SIZE);     // <<<<---- The segfault occurs when backtrace is called
    printf("backtrace() returned %d addresses\n", nptrs);

What libexecinfo is being used?

$ apk info libexecinfo
libexecinfo-1.1-r1 description:
A quick-n-dirty BSD licensed clone of the GNU libc backtrace facility.

libexecinfo-1.1-r1 webpage:
https://www.freshports.org/devel/libexecinfo

libexecinfo-1.1-r1 installed size:
81920

What gcc is being used?

$ apk info gcc
gcc-9.2.0-r2 description:
The GNU Compiler Collection

gcc-9.2.0-r2 webpage:
http://gcc.gnu.org

gcc-9.2.0-r2 installed size:
85364736

Was another c compiler tried?

Yes, I tried with clang, and got the same results.

$ apk info clang
clang-9.0.0-r0 description:
A C language family front-end for LLVM

clang-9.0.0-r0 webpage:
https://llvm.org/

clang-9.0.0-r0 installed size:
18104320

Was the alpine system up to date when the above was tried? Yes, up to date at the time of the filing of this report.

$ cat /etc/apk/repositories
http://dl-cdn.alpinelinux.org/alpine/edge/main
http://dl-cdn.alpinelinux.org/alpine/edge/community
http://dl-cdn.alpinelinux.org/alpine/edge/testing

$ sudo apk update
fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
v20190925-1169-ge75e441ce9 [http://dl-cdn.alpinelinux.org/alpine/edge/main]
v20190925-1182-gc99134e4fc [http://dl-cdn.alpinelinux.org/alpine/edge/community]
v20190925-1182-gc99134e4fc [http://dl-cdn.alpinelinux.org/alpine/edge/testing]
OK: 15091 distinct packages available
$ sudo apk upgrade
OK: 2122 MiB in 496 packages

Are any packages installed that are not from the alpine repos indicated above?

No, only packages available via apk from the above repos are installed in this alpine VM.

Edited Oct 25, 2019 by bogen85
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking