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

segment fault in 64bit-mode #87

Open
ghost opened this issue Apr 3, 2021 · 6 comments
Open

segment fault in 64bit-mode #87

ghost opened this issue Apr 3, 2021 · 6 comments

Comments

@ghost
Copy link

ghost commented Apr 3, 2021

Starting program: /home/fhr/CLionProjects/cb-multios/build64-gcc/challenges/Azurad/Azurad 

Program received signal SIGSEGV, Segmentation fault.
small_alloc_run (heap=<optimized out>) at /home/fhr/CLionProjects/cb-multios/challenges/Azurad/lib/malloc_common.c:224
224         hdr->hdr.prev_size = 0;

Hi,
In 64bit-mode, a lot of programs will crash with the segment fault at the start of the running. It's nearly all about cgc_memory function.
How to solve this problem?
My env:
OS: Ubuntu 20.04LTS
compiler : clang-7/ clang-10 / gcc-7 / gcc-9

@ghost
Copy link
Author

ghost commented Apr 3, 2021

@DarkaMaul

@DarkaMaul
Copy link
Contributor

Hi,
I'm not on my computer right now but I guess the problem comes from uint_ptr type which is too small. I fixed it for one challenge (FUN?) but it should probably be fixed for every other challenges.
I'll try to investigate more next week (prob Tuesday).

@ghost
Copy link
Author

ghost commented Apr 4, 2021

@DarkaMaul Thanks for your reply. I noticed your changes about int&long long int in cgc_stdint.h But I got the same segment fault in FUN challenge.
2021-04-04 10-39-02屏幕截图

Program received signal SIGSEGV, Segmentation fault.
cgc_malloc (size=32) at /home/fhr/CLionProjects/cb-multios-n/challenges/FUN/lib/malloc.c:135
135	      blk->next->prev = nb;

I find the cgc_size_t in libcgc.h. Should I change them into [ long long int ] ?

typedef unsigned long cgc_size_t;
typedef long cgc_ssize_t; 

@ghost
Copy link
Author

ghost commented Apr 4, 2021

@DarkaMaul for example Segment fault in [XStore] 64bit mode.

I fixed the pointer type but got segment fault in another line. So I think that there might be some other parts which should be fixed.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000403254 in run_alloc (heap=0x40c508 <g_heap>, type=2) at /home/fhr/CLionProjects/cb-multios-n/challenges/XStore/lib/malloc_common.c:93
93	    heap->mem_map[alignedi / RUN_SIZE] = type;

image

@DarkaMaul
Copy link
Contributor

I don't have the time to investigate, but here are my observations so far.

However, they are indeed a few problems:

In cgc_malloc.h

#ifdef X32_COMPILE
 #define HEADER_PADDING 24
#else
 #define HEADER_PADDING 48
#endif

The header size was incorrect since it was comprised of multiple pointers.
The command below can be used to change this in a one-liner:

find . -name 'cgc_malloc.h' -exec sed -i "s/\(#define HEADER_PADDING 24\)/#ifdef X32_COMPILE\\n  \1\\n#else\\n  #define HEADER_PADDING 48\\n#endif/" {} \+

Moreover, an improved version of the cgc_stdint.h could be :

#ifdef X32_COMPILE
    # define INT_MIN        INT32_MIN
    # define LONG_MIN       INT32_MIN
    # define INT_MAX        INT32_MAX
    # define UINT_MAX       UINT32_MAX
    # define LONG_MAX       INT32_MAX
    # define ULONG_MAX      UINT32_MAX

    typedef int intptr_t;
    typedef unsigned int uintptr_t;
#else
    # define INT_MIN        INT64_MIN
    # define LONG_MIN       INT64_MIN
    # define INT_MAX        INT64_MAX
    # define UINT_MAX       UINT64_MAX
    # define LONG_MAX       INT64_MAX
    # define ULONG_MAX      UINT64_MAX

    typedef int64_t intptr_t;
    typedef uint64_t uintptr_t;
#endif

However, it is definitely not the only issue. Multiple structures in malloc files depends on the size of the pointers.
For example the cgc_size_to_bin rely on specified size of the headers and should also be modified.

I guess it's easier to say that the challenges are "buildable" towards 64 bits architecture but solely for static analysis as they are not yet runnable.

@ghost
Copy link
Author

ghost commented Apr 6, 2021

@DarkaMaul Thank you very very much. I will try to fix them.
Best wishes!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant