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

Investigate crash #54

Closed
PerMalmberg opened this issue Jul 27, 2019 · 1 comment
Closed

Investigate crash #54

PerMalmberg opened this issue Jul 27, 2019 · 1 comment
Assignees
Labels
Projects

Comments

@PerMalmberg
Copy link
Owner

I (372211) MemStat: [INTERNAL]
I (372222) MemStat: 8-bit F:64700 LB:32664 M:44576 | 32-bit: F:78536 LB:32664 M:58392
I (372224) MemStat: [INTERNAL & DMA]
I (372237) MemStat: 8-bit F:64836 LB:32664 M:44576 | 32-bit: F:64836 LB:32664 M:44576
I (372239) MemStat: [SPIRAM]
I (372253) MemStat: 8-bit F:3356996 LB:3311200 M:3338372 | 32-bit: F:3353884 LB:3311200 M:3338372
I (372255) MemStat: Name	Stack	Min free stack
I (372260) MemStat: MainTask	25600	16316
I (372268) MemStat: SocketDispatcher	20480	2784
I (373340) Socket: [, 0, 57, 0x3fff236c]: Could not get buffer container
I (373345) Socket: [, 0, 57, 0x3fff236c]: Socket stopping
abort() was called at PC 0x401ebf8f on core 0
0x401ebf8f: __cxxabiv1::__terminate(void (*)()) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47


ELF file SHA256: cc3a727c7b571b062530e969af4ca4858f703abea5e0f7a2fd9071d72e7d8c6c

Backtrace: 0x400936e9:0x3ffc5230 0x40093b5c:0x3ffc5260 0x401ebf8f:0x3ffc5290 0x401ebfda:0x3ffc52b0 0x401ec053:0x3ffc52d0 0x401160e6:0x3ffc52f0 0x4011553e:0x3ffc5410 0x40116b36:0x3ffc5510 0x4010afe7:0x3ffc5540 0x40144dc6:0x3ffc5580 0x40144962:0x3ffc5670 0x400d5466:0x3ffc5730 0x40149045:0x3ffc58c0 0x400983ea:0x3ffc58e0
0x400936e9: invoke_abort at /home/permal/esp/esp-idf/components/esp32/panic.c:155

0x40093b5c: abort at /home/permal/esp/esp-idf/components/esp32/panic.c:172

0x401ebf8f: __cxxabiv1::__terminate(void (*)()) at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47

0x401ebfda: std::terminate() at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57

0x401ec053: __cxa_pure_virtual at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/gcc/libstdc++-v3/libsupc++/pure.cc:50

0x401160e6: smooth::application::network::http::HTTPServerClient::send_first_part() at ??:?

0x4011553e: smooth::application::network::http::HTTPServerClient::event(smooth::core::network::event::TransmitBufferEmptyEvent const&) at ??:?

0x40116b36: non-virtual thunk to smooth::application::network::http::HTTPServerClient::event(smooth::core::network::event::TransmitBufferEmptyEvent const&) at ??:?

0x4010afe7: smooth::core::ipc::TaskEventQueue<smooth::core::network::event::TransmitBufferEmptyEvent>::forward_to_event_listener() at ??:?

0x40144dc6: smooth::core::Task::exec() at ??:?

0x40144962: smooth::core::Task::start() at ??:?

0x400d5466: app_main at ??:?

0x40149045: main_task at /home/permal/esp/esp-idf/components/esp32/cpu_start.c:549

0x400983ea: vPortTaskWrapper at /home/permal/esp/esp-idf/components/freertos/port.c:143


CPU halted.

@PerMalmberg PerMalmberg self-assigned this Jul 27, 2019
@PerMalmberg PerMalmberg added this to To do in Smooth via automation Jul 27, 2019
@PerMalmberg PerMalmberg moved this from To do to In progress in Smooth Jul 27, 2019
PerMalmberg added a commit that referenced this issue Jul 27, 2019
@PerMalmberg
Copy link
Owner Author

PerMalmberg commented Jul 27, 2019

Could not get buffer container

That line is interesting as it means that the Socket's weak_ptr to the buffer container no longer has a container. The only way that container can be destroyed is when container in ServerClient is destroyed. Problem is, ServerClient(or rather HTTPServerClient) are all held in a ClientPoolso they are reused and never destroyed. The pool is held by a ServerSocket, in turn held by the HTTPServer. So unless the entire HTTPServer is destroyed, the ownership chain remains intact, making the entire scenario unfeasable.

Then again, the crash is due to a pure function call in send_first_part(), which points to a null pointer being used, such as the container shared_ptr.

So all evidence implies that the HTTPServerClient/ServerClient has been destroyed. The question is how that happened.

@PerMalmberg PerMalmberg moved this from In progress to To do in Smooth Jul 28, 2019
Smooth automation moved this from To do to Done Aug 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Smooth
  
Done
Development

No branches or pull requests

1 participant