# I feel so helpless right now **URL:** \ **Category:** Offtopic\ **Created:** [September 6, 2019, 10:04pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104 "2019-09-06T22:04:10Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![stronny](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/stronny/32/228_2.png) [@stronny](https://forum.crystal-lang.org/u/stronny)\ **Post date:** [September 6, 2019, 10:04pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/1 "2019-09-06T22:04:10Z")
I don’t expect much, but maybe someone has ideas? ```auto {dbg: {13, 0.852736937448849, Pointer(Float64)@0x83ca2c68, Pointer(Fiber::Context)@0x14e2bd4, Pointer(Void)@0x83ca2a6c, Pointer(Fiber::Context)@0x70df1c, Pointer(Void)@0xb64a2c7c}} Thread 1 "tcp-latency" received signal SIGSEGV, Segmentation fault. 0x004a7e5e in swapcontext () at /usr/share/crystal/src/fiber/context/i686.cr:20 (gdb) x/1i 0x004a7e5e => 0x4a7e5e : pop %esi (gdb) info registers eax 0x70df1c 7397148 ecx 0x14e2bd4 21900244 edx 0xd 13 ebx 0x5b9000 6000640 esp 0xb64a2c7c 0xb64a2c7c ebp 0x83ca2bc0 0x83ca2bc0 esi 0x83ca2a6c -2083902868 edi 0x14e2bd4 21900244 eip 0x4a7e5e 0x4a7e5e eflags 0x10202 [IF RF] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 ``` I’m on i686 by the way. The first line is produced by this patch to `resume` (callstack is also made public): ```auto current, @current = @current, fiber a = rand() p dbg: {CallStack.new.callstack.size, a, pointerof(a), pointerof(current.@context), current.@context.stack_top, pointerof(fiber.@context), fiber.@context.stack_top} Fiber.swapcontext(pointerof(current.@context), pointerof(fiber.@context)) ``` ---
**Author:** ![stronny](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/stronny/32/228_2.png) [@stronny](https://forum.crystal-lang.org/u/stronny)\ **Post date:** [September 9, 2019, 2:27pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/2 "2019-09-09T14:27:38Z")
I think I understand now. `esp` has `0xb64a2c7c`, but inspecting `/proc/maps` shows: ```auto b54a3000-b54a4000 ---p 00000000 00:00 0 b54a4000-b5ca3000 rw-p 00000000 00:00 0 b64a3000-b64a4000 ---p 00000000 00:00 0 b64a4000-b6ca3000 rw-p 00000000 00:00 0 ``` So, somehow the memory was freed, in spite of the pointer to it still existing in the program inside `new_context.stack_top`. I should say that what I do is not the documented use of fibers, this one in particular finished already, but if anyone is interested, well, here you go. ---
**Author:** ![bcardiff](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/bcardiff/32/3_2.png) [@bcardiff](https://forum.crystal-lang.org/u/bcardiff)\ **Post date:** [September 9, 2019, 2:53pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/3 "2019-09-09T14:53:14Z")
Maybe you are experiencing the same thing that was solved very recently in [https://github.com/crystal-lang/crystal/pull/8138](https://github.com/crystal-lang/crystal/pull/8138) ---
**Author:** ![stronny](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/stronny/32/228_2.png) [@stronny](https://forum.crystal-lang.org/u/stronny)\ **Post date:** [September 9, 2019, 4:40pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/4 "2019-09-09T16:40:37Z")
I’m really not qualified to give my opinion one way or the other. I’m not using mt though if it makes a difference. ---
**Author:** ![bcardiff](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/bcardiff/32/3_2.png) [@bcardiff](https://forum.crystal-lang.org/u/bcardiff)\ **Post date:** [September 9, 2019, 5:44pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/5 "2019-09-09T17:44:08Z")
Sorry, from > [@stronny](#): > > I should say that what I do is not the documented use of fibers I thought that you might be using fibers with threads, even without the new mt. What is the undocumented use of fibers you are doing? ---
**Author:** ![stronny](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/stronny/32/228_2.png) [@stronny](https://forum.crystal-lang.org/u/stronny)\ **Post date:** [September 9, 2019, 6:04pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/6 "2019-09-09T18:04:50Z")
Subclassing Fiber, patching scheduler, and in general storing fiber instances. I’m starting to think that last bit was a mistake, but why does the GC free the block that is still in use? ---
**Author:** ![rogerdpack](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/rogerdpack/32/117_2.png) [@rogerdpack](https://forum.crystal-lang.org/u/rogerdpack)\ **Post date:** [September 10, 2019, 4:20pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/7 "2019-09-10T16:20:27Z")
I know it only marks “living fibers” as GC heads when it does a GC…wonder if that plays in… ---
**Author:** ![bcardiff](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/bcardiff/32/3_2.png) [@bcardiff](https://forum.crystal-lang.org/u/bcardiff)\ **Post date:** [September 10, 2019, 4:37pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/8 "2019-09-10T16:37:48Z")
The issue I point was because the stack memory of the fibers are in a pool to reduce the stress in the GC. But they were marked as available in the pool before the fiber that was using it has finished. If this is not something that give some idea about what is going wrong in your scenario ignore it. ---
**Author:** ![stronny](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/stronny/32/228_2.png) [@stronny](https://forum.crystal-lang.org/u/stronny)\ **Post date:** [September 10, 2019, 6:10pm UTC](https://forum.crystal-lang.org/t/i-feel-so-helpless-right-now/1104/9 "2019-09-10T18:10:06Z")
I think that’s indeed what’s going on. I was under the impression that stacks are under GC control, however their lifecycle is managed directly with `Fiber::StackPool`. ```auto pointer = LibC.mmap(nil, STACK_SIZE, LibC::PROT_READ | LibC::PROT_WRITE, flags, -1, 0) LibC.munmap(stack, STACK_SIZE) ``` All I have left is a case where with ~100 fibers this behavious occurs, but with ~5 it doesn’t and the program runs well. Thank you very much, I’ve definitely learned something.