Quote:
Originally Posted by Dkt01
Do you have a gdb stack trace for the segfault? It's really difficult to debug the code without knowing where the program is actually failing.
|
I don't know how to use GDB from the terminal. I always use Qt Creator and use the built in Debugger, based off GDB and Valgrind. Sadly, I made a CMakeLists.txt and compiled the application on my pi using that.
I have come up with the conclusion that now seems like the best time to completely rewrite the server.
My previous version was really just me playing around in code and putting something together that works. It worked better than I expected, giving my as low as 4ms responses. However, there were many places where it lacked, like comments/documentation/etc., and had many holes/bugs/etc. Also, I had designed this solely for Google Chrome in mind, so as soon as you launch the web interface in a non-webkit browser such as IE/FireFox(IceWeasel), there are extremely annoying display bugs. Also, the transitions are only for chrome, so the changes are sudden.
Those web-interface bugs are the last on my list to fix. I will be using the same HTML code because it works beautifully, even supporting the ability to detect server/network failures.
Also, I am wondering whether to keep my RAMCache. The RAMCache makes it possible for me to get those 10ms load times for the actual web interface, but it makes it required to relaunch the server just to edit some HTML/JavaScript/CSS code. I think I might add some build configuration options, like the ability to turn on and off the RAMCache. I think I will also add a handler within the web server to recreate the file cache upon a certain action. Maybe I could add an HTML build script to send this signal to the server!