https://opengrok.libreoffice.org/xref/core/external/breakpad/README?r=abf38a15#1

In Windows 10, there is a folder like
%APPDATA%LibreOffice\4\crash
and there are some dmp files.
and there is a file named "dump.ini"

In the ini file you can find where the crash reporter sends data to
https://crashreport.libreoffice.org/submit/

practically you use a text box labeled 'id search' at the top right side of
https://crashreport.libreoffice.org/

there you input the part in the dmp filename before the extension

+1 for UI improvement.

Created attachment 152889 [details]
crash report id should be here

Hello, I believe that crash report ID should be in top textbox of the message. Probably some error on crash reporting server side. We need steps how to reproduce the crash.

himajin100000, you gave us the location of the dump files on a Windows10 system. Do you also know, where they are on a Linux (Ubuntu) system and how they are named?

I'm just a Windows user, and don't use Linux. However, I guess the following code indicates that dumprc is in $HOME/.config/crash/

https://opengrok.libreoffice.org/xref/core/svx/source/dialog/crashreportdlg.cxx?r=ff1bafa9#70
https://opengrok.libreoffice.org/xref/core/desktop/source/app/crashreport.cxx?r=6f50961e#152
https://opengrok.libreoffice.org/xref/core/desktop/source/app/crashreport.cxx?r=6f50961e#119
https://opengrok.libreoffice.org/xref/core/include/sal/config.h?r=e1e39fac#56
https://opengrok.libreoffice.org/xref/core/sal/rtl/bootstrap.cxx?r=3f08be2e#482
https://opengrok.libreoffice.org/xref/core/configure.ac?r=231fb044#3129
https://opengrok.libreoffice.org/xref/core/include/osl/security.hxx?r=189abcf0#86
https://opengrok.libreoffice.org/xref/core/sal/osl/unx/security.cxx?r=f665456c#416
https://opengrok.libreoffice.org/xref/core/sal/osl/unx/security.cxx?r=f665456c#353
https://opengrok.libreoffice.org/xref/core/sal/osl/unx/security.cxx?r=f665456c#363

oops, the filename wasn't dumprc, dump.ini is the correct one.

as there is no  SAL_CONFIGFILE("dump")
https://opengrok.libreoffice.org/xref/core/desktop/source/app/crashreport.cxx?r=6f50961e#154

(In reply to himajin100000 from comment #1)
> https://opengrok.libreoffice.org/xref/core/external/breakpad/
> README?r=abf38a15#1
...
> 
> there you input the part in the dmp filename before the extension

Unfortunately non of the opengrok.libreoffice.org links works for me.

(In reply to himajin100000 from comment #6)
> I'm just a Windows user, and don't use Linux. However, I guess the following
> code indicates that dumprc is in $HOME/.config/crash/
> 
> https://opengrok.libreoffice.org/xref/core/svx/source/dialog/crashreportdlg.
> cxx?r=ff1bafa9#70
> ...
> https://opengrok.libreoffice.org/xref/core/sal/osl/unx/security.
> cxx?r=f665456c#363

Unfortunately there is no directory in the hidden config directory, neither for the normal user nor for the administrative accounz under which LibreOffice was installed.

(In reply to himajin100000 from comment #7)
> oops, the filename wasn't dumprc, dump.ini is the correct one.
> 
> as there is no  SAL_CONFIGFILE("dump")
> https://opengrok.libreoffice.org/xref/core/desktop/source/app/crashreport.
> cxx?r=6f50961e#154

On my whole Linux computer, there is no file named dumprc and no file named dump.ini.

Hmmm, I guess:

* Official RELEASE builds uses options specified in the appropriate conf files.
https://opengrok.libreoffice.org/xref/core/distro-configs/

And they contains --enable-breakpad

* However, for example, Nightlies and Beta versions do not use these options, and 
in your first post, "Thank you for your help in improving *LibreOfficeDev*.", which indicates you are using those versions.

* if we don't have that option when the program is built, writeCommonInfo will not run, so there will be no dump.ini
https://opengrok.libreoffice.org/xref/core/desktop/source/app/app.cxx?r=2ec1c7a6#2086

(In reply to raal from comment #3)
> Created attachment 152889 [details]
> crash report id should be here
> 
> Hello, I believe that crash report ID should be in top textbox of the
> message. Probably some error on crash reporting server side. We need steps
> how to reproduce the crash.

Adalbert, normally you only have to copy ID and paste it into browser. If there is no crash ID it could be a bug. As raal wrote, please give us some steps to reproduce and also informations from Help => About LibreOffice.

AFAIK there is no crash ID in a developer version (but I might be wrong)

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided.

(In reply to Dieter Praas from comment #12)
> (In reply to raal from comment #3)
...
> 
> Adalbert, normally you only have to copy ID and paste it into browser. If
> there is no crash ID it could be a bug. As raal wrote, please give us some
> steps to reproduce and also informations from Help => About LibreOffice.
> 
> AFAIK there is no crash ID in a developer version (but I might be wrong)
> 
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' once the steps are provided.

I just encountered another message that LO Writer crashed and wants to recover the documents on which I worked last. The crash message still looked the same as when I reported this bug. It did not tell me any crash ID.

This happened with LO Writer Version: 6.4.0.0.alpha0+
Build ID: 0fb2927a8fe06e6c3255544b8e4c4c9c0f5a67d3
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-08-27_22:50:23
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded

I think it is especially important for the development version that it creates crash reports. Also the message which comes up after a crash report should give more information on the type of bug and it should ask some information in addition from the user, e.g.

1. How was the CPU usage and the memory usage at the moment, when the crash happened (I have a small indicator on by task bar which roughly tells me, if the CPU is at its limits or if memory is congested or if swapping takes place, so I have an idea if this could be the cause),
2. If LO just did not respond,
3. If the rest of the computer reacted to user input or if it was also tremendously slowed down,
4. How many documents were open (and are proposed to be reconstructed) when the crash happened?
what is the file size of those files (in MB, also in estimated number of pages when printed - at least for the document which was under work when the crash happened)
5. If the user remembers what he did last before the crash happened.
6. Any other reasonable question the programmers conceive.

Since the message of a past crash event happens after it by some other program than just the crashed LO, it certainly could collect and communicate such reasonable information to the programmers/debuggers.

I will confirm for a specific reason: attachment 152887 [details] shows similar to what happens to me in Linux Mint now with LO master 6.4+: there's no URL to crash report. 
I conclude Adalbert also has Linux, so I set so.

Created attachment 154157 [details]
Crash report without URL

Same in Windows with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 01837a85004a6f891a09c0a63ed7eff75d634827
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_00:07:05
Locale: en-GB (de_DE); UI-Language: en-US
Calc: threaded

You only get a valid URL if the LibreOffice version is in http://crashreport.libreoffice.org/ and the symbols are uploaded to the server and we only do that for final releases.
Getting an empty with a master build is expected.
Closing as RESOLVED NOTABUG

This bug report was opened to improve the process of bug elimination especially in the current development versions. For the development process getting detailed information on the circumstances is even more important than for released stable versions for three reasons:

1. Bugs which are eradicated in the development version don’t get through to a released version.
2. Probably there are more bugs in it than in a released version.
3. Users of the development versions tend to have a more technical look on bugs and probably can report them more thoroughly than a standard user, since one might expect them to have more software-constrution-related attitude than a standard user.

Of course every user who encounters a should report them, no matter what her/his background is. 

With the intention of the starting point in view, closing the thread as NOTABUG is not reasonable. There is much room for improvement in bug reporting, as indicated in the opening of this thread.

Finally, even in the statement closing as NOTABUG, the bureaucratic argument itself should have triggered the question: How can we improve the processing of crash reports for the current development version? 

Being able to upload the symbols to the server might be fundamental to evaluate crash reports if they pertain to different versions. I can’t judge if it would increase the effort to create and to distribute the development version in a state which would enable uploading the symbols to the server also for them. Also the number of crash reports coming in that way might increase the amount of data to be handled by the server significantly. If this is the case, still the questions

* What did the user do immediately before the crash happened (if he can remember it)? In my case the crashes happened so much like a flash from the clear sky, that I was unable to give such a hint.

* What additional Information to classify the crash can the user provide if it can’t be provided automatically (like the type of crash and a minimal version of the caller stack)?

* Since the crash message explicitly asks the user
„Please check the report and if no bug report is connected to the crash report yet, open a new bug report at bugs.documentfoundation.org. Add detailed instructions on how to reproduce the crash and then show crash ID into the crash report field. ...”
there should be a way to enter something about the circumstances. 
But the user has to know.

* Where does he find the crash report? Is it in his file system? Where?
* What exactly shall he check for?
* Where can he enter the description of what he did before the crash happened?

So the development version should behave similar to the released version at least by creating such minimal crash reports at least locally, even if they are not uploaded as a whole in case of a crash.

So even if it might be impractical to handle crash reporting in the development version exactly as in the released versions, I would advocate to replace the crash reporting part of it by another one, better suited for this special purpose (especially since – if this is the case – crash reporting already differs from that of the released version: Why not improve that further to improve the development process). 

Adding questions about the circumstances of the crash from the user’s standpoint as indicated in my original post should be considered even for the released versions. When I searched for bugs in software I often considered questions like those proposed above. This additional information often helps more than automatic dump reports. Of course dump reports play an important role, but their use is in the second step after one as an idea what might have gone wrong.

(In reply to Adalbert Hanßen from comment #18)
> This bug report was opened to improve the process of bug elimination
> especially in the current development versions. For the development process
> getting detailed information on the circumstances is even more important
> than for released stable versions for three reasons:
> 
> 1. Bugs which are eradicated in the development version don’t get through to
> a released version.
> 2. Probably there are more bugs in it than in a released version.
> 3. Users of the development versions tend to have a more technical look on
> bugs and probably can report them more thoroughly than a standard user,
> since one might expect them to have more software-constrution-related
> attitude than a standard user.

Totally agree with you.
But I don't see how the crashreport instance can help here. We already have debug builds for getting crash backtraces so not having the crashreport working with daily builds is not blocking us at all

(In reply to Timur from comment #20)
> I also agree with Adalbert and think this should be set as Enhancement. 
> I don't think that crash backtraces (that should be useful once dev looks
> into a bug) are the same as Crash Report (that may reveal similar crashes,
> versions and frequency).

I agree, too.

I open this because I experience the lack of this link.
For example, I test fix in bug 124729 and I again get crash report but I cannot see it and write it there.

Xisco, what is the aim of the crash report window, if there is no link to the crash report? Crash report tells me that I shall check the report and connect it to a bug report. This is completely useless without a link. So I see two possibilities:
a) add link (I would prefer this)
b) skip crash report window, if no link is created

Same issue in Bug 126368, I got a crash with master, otherwise not easily reproducible, that I cannot write. 
Is there any reason why we wouldn't have links in Crash report for master?

(In reply to Timur from comment #26)
> Same issue in Bug 126368, I got a crash with master, otherwise not easily
> reproducible, that I cannot write. 
> Is there any reason why we wouldn't have links in Crash report for master?

I've said it before, we don't upload master symbols to the crashreport instance. The final releases already use thousands of gbs for their symbols and we upload new ones every week.

(In reply to Xisco Faulí from comment #27)
> I've said it before, we don't upload master symbols to the crashreport
> instance. The final releases already use thousands of gbs for their symbols
> and we upload new ones every week.

If this is the case we should skip crash report window in master, because it is useless (see comment 24).

(In reply to Xisco Faulí from comment #27)

> I've said it before, we don't upload master symbols to the crashreport
> instance. The final releases already use thousands of gbs for their symbols
> and we upload new ones every week.

The very end of my post seems to have been overseen in this discussion:

Would it not be possible to show the type of crash reason (e.g. lost pointer, violated assertion or whatever can be distinguished in such a tragic situation). 

To help the user, one might ask him about the number of files open simultaneously in LO, if there were some with multiple windows among them, give the user some multiple choice field what he did (leaving a freely editable one) and other things someone hunting for bugs will be interested in. Possibly interesting questions associated with it also might be
    • Could your currently open files be restored?
    • Did you notice there significant losses in the reconstructed file(s)?

(In reply to Xisco Faulí from comment #27)
> we don't upload master symbols to the crashreport instance. 

I don't understand what it means but this should be resolved in either of ways:
- to solve prerequisite (upload master symbols) and give crash report link on master
- to assess that's not acceptable, explain why. 
And close this issue.

There is no functional use of the Breakbad generated crash dumps without corretly linked symbols. They need to be present locally or on the project crashreport server--which we won't/can't do. 

Like Dieter, agree the crash report dialog should be fully suppressed. The partial dialog now on recovery is only confusing for folks on dev builds of master that do not contain the "--enable-breakpad" build string.

Fully suppressing the dialog for dev builds is a valid issue.

The other concerns here are better handled by improving guidance for working with debug builds and local symbol cache [refs].

For dev builds, dumping Breakpad reports in bulk back to a central service is no substitute to a few well crafted backtraces once details of a crash with steps-to-reproduce (STR) have been reported.

Crafting the backtrace locally allows each user to account for the actions they take to reproduce the issue with refined STR.

=-refs-=
https://wiki.documentfoundation.org/Development/How_to_debug
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information
https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg

(In reply to Dieter from comment #32)
> (In reply to V Stuart Foote from comment #31)
> > There is no functional use of the Breakbad generated crash dumps without
> > corretly linked symbols. They need to be present locally or on the project
> > crashreport server--which we won't/can't do. 
> > 
> > Like Dieter, agree the crash report dialog should be fully suppressed. The
> > partial dialog now on recovery is only confusing for folks on dev builds of
> > master that do not contain the "--enable-breakpad" build string.
> > 
> > Fully suppressing the dialog for dev builds is a valid issue.
> 
> Xisco, what is your opinion?  For me it's O. K., if you decide or a decision
> is madein the next QA meeting. I think a decision is needed, because bug was
> reported more than a half year ago.

Yep, I think it's a good idea

(In reply to Xisco Faulí from comment #27)
> (In reply to Timur from comment #26)
> > Same issue in Bug 126368, I got a crash with master, otherwise not easily
> > reproducible, that I cannot write. 
> > Is there any reason why we wouldn't have links in Crash report for master?
> 
> I've said it before, we don't upload master symbols to the crashreport
> instance. The final releases already use thousands of gbs for their symbols
> and we upload new ones every week.

Crash report working for daily DEV builds is maybe not the best thing to do.. However, I would like a crash reporter edition for 'release' builds in Alpha/Beta/RC area.

1. to check for symbolic issues.. before
2. BT of mine tend to have a different outcome

Today I encountered a crash. This incident makes me revisit this already older incident, although it has already raised such a long discussion. Now got a crash report which lets me upload crash information and the told me

"The crash report was successfully uploaded.
You can soon find the report at: https://crashreport.libreoffice.org/stats/crash_details/8f94a6b3-c47e-4a3f-958e-4fc41-6554535"

First remark: I could not copy from the window with the error message as I had wanted to. I only could make a screenshot of it, paste it to an OCR program and have the text recognized there. Of course, this is an unnecessarily complicated diversions, but it is still better and safer than typing out such a long URL.

Second remark: Even after some hours after letting it report the error, I could not open the URL. So I am not sure, if it really was uploaded.

Third remark: I would have told you something about what I did before the crash happened. This one happened with a development version, but I bet it also happens in released versions.

If you want to describe an error situation precisely, you should not be distracted by writing down long URLs and the like, but get directly to a place where you can give as precise answers as possible about the antecedents of an error. This could be further supported if a few well-designed questions were asked at this point first: 

* A first set of questions for possible triage, which errors are investigated at all and which only if they have occurred more frequently. Possible question should be if this appears to be the first time to the user, or if it has happened more often, if severe data loss has occurred and the like. The system should then automatically indicate whether that particular error (from the automatic upload of the crash report) is more likely or not to be investigated further. A number between 0 (not likely) to 10 (almost certain case) should indicate this. 

* Then the person reporting the error can decide whether it is worth the effort to provide more detailed information from a second set of questions targeted to pin down what has caused the error. To do this, the rest of the questionnaire should be displayed with the possibility of a free text field at the end.