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.

Sign up for GitHub

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

Jump to bottom

"Forward" takes too long with no information about actions #9

Closed
mozeq opened this issue Feb 4, 2013 · 2 comments
Closed

"Forward" takes too long with no information about actions #9

mozeq opened this issue Feb 4, 2013 · 2 comments

Comments

@mozeq
Copy link
Contributor

mozeq commented Feb 4, 2013

Opened '20090226T12:48:10' by mhlavink as https://fedorahosted.org/abrt/ticket/9

after clicking "Forward" button "something" happens, but it's not interactive - no progress bar (not required), but also no information what it is doing. Is it downloading -debuginfo? It can take a long time and user doesn't know if it is still working or if it hanged up.
@mozeq
Copy link
Contributor Author

mozeq commented Feb 4, 2013

Added '20090226T21:42:02' by 'jlaska'

I believe it is downloading debuginfo packages. A simple progress bar would be a great interim solution until debugfs is online.

@mozeq mozeq closed this as completed Feb 4, 2013
@mozeq
Copy link
Contributor Author

mozeq commented Feb 4, 2013

Added '20090312T13:20:45' by 'mnowak'

simple progress bar is there -- abrt-0.0.2-1.fc11.x86_64

This was referenced Feb 4, 2013
Closed
Closed
Closed
Closed
jfilak pushed a commit to jfilak/abrt that referenced this issue Jul 20, 2016
Extended btp_abrt_report_from_dir to support Java, koops, Python stac…
e6ab6e5 
…ktraces.

Added Java stacktrace support to report.

Fixes abrt#9.
Fixes abrt#8.
Fixes abrt#7.
msrb added a commit to msrb/abrt that referenced this issue Feb 18, 2024
@msrb
ccpp: don't fail bug reporting on ureport failure
8c6da86 
Related: gh#1656

ureport works with the core backtrace retrieved from coredumpctl,
but the backtrace is sometimes quite useless:

    Stack trace of thread 3219:
    #0  0x0000aaaaca9d02dc crash.constprop.0 (will_segfault + 0x102dc)
    abrt#1  0x0070aaaaca9d0370 n/a (n/a + 0x0)
    ...
    abrt#9  0x0013ffff8dd40abc n/a (n/a + 0x0)
    abrt#10 0x0076aaaaca9d0170 n/a (n/a + 0x0)
    ELF object binary architecture: AARCH64

abrt (understadably) complains about such low value backtrace and refuses
to continue. However, when we later run gdb on the coredump,
we actually get a good backtrace out of it.

This commit makes ureport failures non-blocking and thus there is a chance
that we will get a good quality backtrace from gdb later.

Signed-off-by: Michal Srb <michal@redhat.com>
msrb added a commit to msrb/abrt that referenced this issue Feb 18, 2024
@msrb
ccpp: don't fail bug reporting on ureport failure
abf201f 
Related: gh#1656

ureport works with the core backtrace retrieved from coredumpctl,
but the backtrace is sometimes quite useless:

    Stack trace of thread 3219:
    #0  0x0000aaaaca9d02dc crash.constprop.0 (will_segfault + 0x102dc)
    abrt#1  0x0070aaaaca9d0370 n/a (n/a + 0x0)
    ...
    abrt#9  0x0013ffff8dd40abc n/a (n/a + 0x0)
    abrt#10 0x0076aaaaca9d0170 n/a (n/a + 0x0)
    ELF object binary architecture: AARCH64

abrt (understadably) complains about such low value backtrace and refuses
to continue. However, when we later run gdb on the coredump,
we actually get a good backtrace out of it.

This commit makes ureport failures non-blocking and thus there is a chance
that we will get a good quality backtrace from gdb later.

Signed-off-by: Michal Srb <michal@redhat.com>
msrb added a commit that referenced this issue Feb 18, 2024
@msrb
ccpp: don't fail bug reporting on ureport failure
9652169 
Related: gh#1656

ureport works with the core backtrace retrieved from coredumpctl,
but the backtrace is sometimes quite useless:

    Stack trace of thread 3219:
    #0  0x0000aaaaca9d02dc crash.constprop.0 (will_segfault + 0x102dc)
    #1  0x0070aaaaca9d0370 n/a (n/a + 0x0)
    ...
    #9  0x0013ffff8dd40abc n/a (n/a + 0x0)
    #10 0x0076aaaaca9d0170 n/a (n/a + 0x0)
    ELF object binary architecture: AARCH64

abrt (understadably) complains about such low value backtrace and refuses
to continue. However, when we later run gdb on the coredump,
we actually get a good backtrace out of it.

This commit makes ureport failures non-blocking and thus there is a chance
that we will get a good quality backtrace from gdb later.

Signed-off-by: Michal Srb <michal@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mozeq