In the progression from v2.1.0 to Github latest r.cbcb0e2, ede-launch no longer calls start_child_process directly but does so via start_child_process_with_core where (if the OS is not Minix) it tries to change the limit size of core dump files to RLIM_INFINITY without any checking of the permitted maximum size.
This is a procedural error.
Before trying to set the new limit size, it must first test if the new desired size RLIM_INFINIT is less than the permitted maximum
getrlimit(RLIMIT_CORE, &rlim);
if (!(RLIM_INFINITY > rlim.rlim_max))
{
... set new limit ...
}
otherwise setrlimit with RLIM_INFINITY results in
setrlimit() failed with Invalid argument
and ede-lauch exits with an error and thus no programs can be launched from the panel start menu or panel run-command box.
Now since EDE is intended for low resource systems, it should be anticipated that the limit on core dump sizes may most probably be set system wide to 0, and thus this whole procedure is pointless other than for debugging purposes.
Therefore I suggest that in normal operation, ede-launch should, as in the last official release, call start_child_process, directly and that the "diversion" start_child_process_with_core should only be used and the function only compiled in, if the debugging flag has been set with --enable-debug when the configure script is executed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Idea behind start_child_process_with_core() is to create a dump when started application crashes and invoke ede-crasher to spawn gdb on it, trying to get stacktrace. This is useful for EDE apps when they crashes, ede-crasher will try to submit stacktracte to bugzilla (which is offline for now).
If you see in ede-launch.cpp file, ede-crasher will be invoked only for EDE apps.... Now, I could add it to (try) to change limit size for the sake of core dump only for EDE apps and keep it as is for other applications?
I'm aware that optimized builds without debug symbols will not produce readable stacktraces, but getting any useful report and backtrace from users not familiar with gdb is hard as well.
What other implications are of setting new limit sizes, rather than default?
Best,
Sanel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand why you would want to save core files for bug hunting but in normal operation my feeling is that it only adds bloat to the compiled code and slows down the launching of applications (which again is more significant on slower machines for which EDE is the main target).
At a very minimum, the code needs to check if the coredump size maximum allows a size greater than zero.
My feeling is still that this feature (which is a useful one to have for diagnostics) should onl be present in debug mode and the code being run has been compiled with -g and the resulting binary NOT stripped.
And yes creating a stacktrace is not so simple, which is why I have a shell script to do it, which at its core has the command (with the logfile variable set previously with
logfile="${tmp_dir}/backtrace-${executable}-${timestamp}.log")
Perhaps the above (which was gleaned from either the Debian or Ubuntu HOWTO on creating a backtrace, so all credit to them) can be of some use to others?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the progression from v2.1.0 to Github latest r.cbcb0e2, ede-launch no longer calls start_child_process directly but does so via start_child_process_with_core where (if the OS is not Minix) it tries to change the limit size of core dump files to RLIM_INFINITY without any checking of the permitted maximum size.
This is a procedural error.
Before trying to set the new limit size, it must first test if the new desired size RLIM_INFINIT is less than the permitted maximum
otherwise setrlimit with RLIM_INFINITY results in
setrlimit() failed with Invalid argument
and ede-lauch exits with an error and thus no programs can be launched from the panel start menu or panel run-command box.
Now since EDE is intended for low resource systems, it should be anticipated that the limit on core dump sizes may most probably be set system wide to 0, and thus this whole procedure is pointless other than for debugging purposes.
Therefore I suggest that in normal operation, ede-launch should, as in the last official release, call start_child_process, directly and that the "diversion" start_child_process_with_core should only be used and the function only compiled in, if the debugging flag has been set with --enable-debug when the configure script is executed.
Hi,
Again, good catch!
Idea behind start_child_process_with_core() is to create a dump when started application crashes and invoke ede-crasher to spawn gdb on it, trying to get stacktrace. This is useful for EDE apps when they crashes, ede-crasher will try to submit stacktracte to bugzilla (which is offline for now).
If you see in ede-launch.cpp file, ede-crasher will be invoked only for EDE apps.... Now, I could add it to (try) to change limit size for the sake of core dump only for EDE apps and keep it as is for other applications?
I'm aware that optimized builds without debug symbols will not produce readable stacktraces, but getting any useful report and backtrace from users not familiar with gdb is hard as well.
What other implications are of setting new limit sizes, rather than default?
Best,
Sanel
Thank you for your considertaion of my comments.
I understand why you would want to save core files for bug hunting but in normal operation my feeling is that it only adds bloat to the compiled code and slows down the launching of applications (which again is more significant on slower machines for which EDE is the main target).
At a very minimum, the code needs to check if the coredump size maximum allows a size greater than zero.
My feeling is still that this feature (which is a useful one to have for diagnostics) should onl be present in debug mode and the code being run has been compiled with -g and the resulting binary NOT stripped.
And yes creating a stacktrace is not so simple, which is why I have a shell script to do it, which at its core has the command (with the logfile variable set previously with
logfile="${tmp_dir}/backtrace-${executable}-${timestamp}.log")
Perhaps the above (which was gleaned from either the Debian or Ubuntu HOWTO on creating a backtrace, so all credit to them) can be of some use to others?