Re: ABRT for Ruby
by Vít Ondruch
Dne 10.7.2012 16:12, John5342 napsal(a):
> On Tue, Jul 10, 2012 at 9:29 AM, Vít Ondruch <vondruch(a)redhat.com> wrote:
>> You are right, you can change the $PROGRAM_NAME. I'll make several points
>> here
>>
>> * Is there some more reliable way how to detect the script name?
>> * What is the use case and how widely is this practice used? Can we ignore
>> this case? Python handler ignores it if I am not mistaken (but we should be
>> better of course ;)
>> * ABRT ignores such failure and it just logs something like "Executable
>> 'foo.rb' doesn't belong to any package" into /var/log/messages.
> If the Ruby documentation is to be believed you could use
> Kernel#caller to get a stack trace which apparently has a set format
> including the file name. It is of course swapping a user modifiable
> value for something slightly more fragile (it could potentially change
> in some future version). Perhaps use the current way and fall back to
> Kernel#caller if $0 doesn't resolve to a real file (which would
> indicate it has been modified.
>
> None of this of course covers scenarios where user/other code is
> loaded from within another program (think rake, thor, etc) but in the
> case of an exception, Exception#backtrace is the same format as
> Kernel#caller.
>
John, thank you. Use of the Exception#backtrace is nice idea! Have to
take a look into.
It might be even possible to extract the "latest gem" in the backtrace
and assign the bug to it, but I am not sure if that is good idea, since
the error might be in the gem as well as in its caller. In that case, I
would expect that the library consumer/application author has "more"
knowledge about the library then the library author about the
consumer/application. Thoughts?
Vit
11 years, 10 months
[PATCH v2] report-newt : remove report-only support
by Jakub Filak
- dummy report-only command line option removed
- report-newt has never executed any analyze event
Signed-off-by: Jakub Filak <jfilak(a)redhat.com>
---
src/report-newt/report-newt.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/src/report-newt/report-newt.c b/src/report-newt/report-newt.c
index 034beac..3a94896 100644
--- a/src/report-newt/report-newt.c
+++ b/src/report-newt/report-newt.c
@@ -379,28 +379,24 @@ int main(int argc, char **argv)
/* Can't keep these strings/structs static: _() doesn't support that */
const char *program_usage_string = _(
- "& -o [-d] DIR\n"
+ "& [-d] DIR\n"
"\n"
"newt tool to report problem saved in specified DIR"
);
enum {
- OPT_o = 1 << 0, // report only
- OPT_r = 1 << 1,
- OPT_V = 1 << 2,
+ OPT_r = 1 << 0,
+ OPT_V = 1 << 1,
};
/* Keep enum above and order of options below in sync! */
struct options program_options[] = {
- OPT_BOOL('o', "report-only", NULL, _("Skip analyze steps, go through report steps only")),
OPT_BOOL('d', "delete", NULL, _("Remove DIR after reporting")),
OPT_BOOL('V', "version", NULL, _("Display version and exit")),
OPT_END()
};
unsigned opts = parse_opts(argc, argv, program_options, program_usage_string);
argv += optind;
- /* zero or >1 arguments with -o, or >0 arguments with -V */
- if (!(opts & (OPT_o | OPT_V)) ||
- ((opts & OPT_o) && (!argv[0] || argv[1])) ||
- ((opts & OPT_V) && argv[0]))
+ /* >0 arguments with -V */
+ if ((opts & OPT_V) && argv[0])
show_usage_and_die(program_usage_string, program_options);
if (opts & OPT_V)
--
1.7.10.4
11 years, 10 months
[PATCH 1/4] report_problem_in_dir() never uses report-only option (always perform analysis)
by Jakub Filak
Signed-off-by: Jakub Filak <jfilak(a)redhat.com>
---
src/include/report.h | 5 ++++-
src/lib/report.c | 8 +-------
src/report-python/reportmodule.c | 3 ++-
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/src/include/report.h b/src/include/report.h
index 21557ac..9100c7c 100644
--- a/src/include/report.h
+++ b/src/include/report.h
@@ -31,7 +31,8 @@ enum {
LIBREPORT_GETPID = (1 << 1), /* return pid of child. Use with LIBREPORT_NOWAIT. */
/* Note: without LIBREPORT_GETPID, child will be detached */
/* (reparented to init) */
- LIBREPORT_ANALYZE = (1 << 2), /* run analyzers? */
+ /* Deprecated option. Configure your events properly. */
+ /* LIBREPORT_ANALYZE = (1 << 2);*/ /* run analyzers? */
/* ("run reporters" is always on, has no flag (for now?)) */
LIBREPORT_RELOAD_DATA = (1 << 5), /* reload problem data after run (needs WAIT) */
LIBREPORT_DEL_DIR = (1 << 6), /* delete directory after reporting (passes --delete to child) */
@@ -39,6 +40,8 @@ enum {
LIBREPORT_RUN_NEWT = (1 << 8), /* run 'report-newt' */
};
+
+
typedef enum {
LR_OK = 0,
LR_MISSING_ITEM = (1 << 1),
diff --git a/src/lib/report.c b/src/lib/report.c
index 09dbaac..7d7fbd6 100644
--- a/src/lib/report.c
+++ b/src/lib/report.c
@@ -44,8 +44,6 @@ int report_problem_in_dir(const char *dirname, int flags)
*pp++ = (char *)"report-gtk";
if (flags & LIBREPORT_DEL_DIR)
*pp++ = (char *)"--delete";
- if (!(flags & LIBREPORT_ANALYZE))
- *pp++ = (char *)"--report-only";
*pp++ = (char *)"--";
*pp++ = (char *)dirname;
*pp = NULL;
@@ -65,7 +63,6 @@ int report_problem_in_dir(const char *dirname, int flags)
*pp++ = (char *)"report-newt";
if (flags & LIBREPORT_DEL_DIR)
*pp++ = (char *)"--delete";
- *pp++ = (char *)"-o"; /* report only, newt can't analyze */
*pp++ = (char *)"--";
*pp++ = (char *)dirname;
*pp = NULL;
@@ -80,10 +77,7 @@ int report_problem_in_dir(const char *dirname, int flags)
*pp++ = (char *)"report-cli";
if (flags & LIBREPORT_DEL_DIR)
*pp++ = (char *)"--delete";
- if (!(flags & LIBREPORT_ANALYZE))
- *pp++ = (char *)"-ro"; /* only report */
- else
- *pp++ = (char *)"-r"; /* analyze and report */
+ *pp++ = (char *)"-r"; /* analyze and report */
*pp++ = (char *)"--";
*pp++ = (char *)dirname;
*pp = NULL;
diff --git a/src/report-python/reportmodule.c b/src/report-python/reportmodule.c
index 5fdb786..3f998b9 100644
--- a/src/report-python/reportmodule.c
+++ b/src/report-python/reportmodule.c
@@ -91,7 +91,8 @@ init_pyreport(void)
PyModule_AddObject(m, "LIBREPORT_NOWAIT" , Py_BuildValue("i", LIBREPORT_NOWAIT ));
PyModule_AddObject(m, "LIBREPORT_WAIT" , Py_BuildValue("i", LIBREPORT_WAIT ));
PyModule_AddObject(m, "LIBREPORT_GETPID" , Py_BuildValue("i", LIBREPORT_GETPID ));
- PyModule_AddObject(m, "LIBREPORT_ANALYZE" , Py_BuildValue("i", LIBREPORT_ANALYZE ));
+ /* Deprecated option. Configure your events properly. */
+ /* PyModule_AddObject(m, "LIBREPORT_ANALYZE" , Py_BuildValue("i", LIBREPORT_ANALYZE )); */
PyModule_AddObject(m, "LIBREPORT_RELOAD_DATA", Py_BuildValue("i", LIBREPORT_RELOAD_DATA));
PyModule_AddObject(m, "LIBREPORT_DEL_DIR" , Py_BuildValue("i", LIBREPORT_DEL_DIR ));
PyModule_AddObject(m, "LIBREPORT_RUN_CLI" , Py_BuildValue("i", LIBREPORT_RUN_CLI ));
--
1.7.10.2
11 years, 10 months
Re: ABRT for Ruby
by Vít Ondruch
Hi Motohiro,
Thank you for your feedback.
Dne 9.7.2012 22:46, KOSAKI Motohiro napsal(a):
> On Mon, Jul 9, 2012 at 9:47 AM, Vít Ondruch <vondruch(a)redhat.com> wrote:
>> Hi,
>>
>> Updated ABRT gem version 0.0.2 is available at RubyGems.org if you like to
>> test it. I'd love to hear some feedback.
>>
>> There were done following changes:
>>
>> * Improved code base
>> * Better handling of some edge cases, such as call to Kernel#exit or Ctrl+C
>> event
>> * Test suite added
>> * Improved documentation
>>
>> I also prepared RPM for Fedora. Review is available at
>> https://bugzilla.redhat.com/show_bug.cgi?id=838568
>
>> def self.report(backtrace, io = abrt_socket)
>> io.write "PUT / HTTP/1.1\r\n\r\n"
>> io.write "PID=#{Process.pid}\0"
>> io.write "EXECUTABLE=#{$PROGRAM_NAME}\0"
> Hmm..
>
> If I understand correctly, EXECUTABLE key is used for looking up package name
> from abrt daemon. Then, It should be realfilename. See below abrt doc.
>
>
> abrt/doc/interpreted-languages:
>
>> EXECUTABLE
>> The file with the main entry point of the application. Might be a JAR
>> archive, a script file, a bytecode file, or the interpreter. It should
>> be a real file on the filesystem, so ABRT can check the origin of the
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> However, PROGRAM_NAME can be changed from ruby scripting. e.g.
> $0 = "foobar"
You are right, you can change the $PROGRAM_NAME. I'll make several
points here
* Is there some more reliable way how to detect the script name?
* What is the use case and how widely is this practice used? Can we
ignore this case? Python handler ignores it if I am not mistaken (but we
should be better of course ;)
* ABRT ignores such failure and it just logs something like "Executable
'foo.rb' doesn't belong to any package" into /var/log/messages.
>
>
>> # TODO: Do we need specialized Ruby analyzer?
>> # io.write "ANALYZER=Ruby\0"
>> io.write "ANALYZER=Python\0"
>> io.write "BASENAME=rbhook\0"
>> io.write "REASON=#{backtrace.first}\0"
>> io.write "BACKTRACE=#{backtrace.join("\n")}\0"
> btw, I wrote a patch to redirect rb_bug() message to abrtd too.
> Is it interesting for you?
>
> https://github.com/kosaki/ruby/commit/6283017dc2747f306808ce530292dc51273...
I'll take a closer look later if you don't mind, but could you please
elaborate the patch a bit? I know you have risen some concerns
previously. What is advantage of your patch or how is it different? What
scenarios it should handle and what not?
Thank you.
Vit
11 years, 10 months
[PATCH] add missing dd_close() to save_dump_dir_from_problem_data()
by Jakub Filak
- this missing dd_close() causes trac#608
Signed-off-by: Jakub Filak <jfilak(a)redhat.com>
---
src/lib/create_dump_dir.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/lib/create_dump_dir.c b/src/lib/create_dump_dir.c
index 175cb61..2195a80 100644
--- a/src/lib/create_dump_dir.c
+++ b/src/lib/create_dump_dir.c
@@ -171,12 +171,15 @@ LibreportError save_dump_dir_from_problem_data(problem_data_t *problem_data, cha
VERB2 log("Renaming from'%s' to '%s'", dd->dd_dirname, new_path);
if (dd_rename(dd, new_path) != 0)
{
+ free(new_path);
+ dd_close(dd);
+
free(*problem_id);
*problem_id = NULL;
return LR_ERROR;
}
- free(new_path);
+ free(new_path);
dd_close(dd);
return LR_OK;
--
1.7.10.2
11 years, 10 months