Stacked on the steps 1-3 branch (feature-diagnostic-logging, PR #646).
Kept as its own PR rather than folded into that one, matching the
discussion's own framing: step 4 is explicitly "the highest-risk piece
... lands last, behind its own switch."
## Step 4 -- crash-time ring flush (CrashHandler)
Installs a handler for SIGSEGV/SIGABRT/SIGBUS/SIGFPE/SIGILL (POSIX) /
SetUnhandledExceptionFilter (Windows) that flushes the in-memory ring to
a fixed crash_dump.log before the process dies.
This required reworking LogRing (step 3) to be genuinely lock-free, not
just mutex-protected: a signal handler that blocks on a lock the
crashing thread (or another thread) already holds turns a clean crash
into a hang -- no ring dump *and* no core dump, worse than doing
nothing. append() now claims a slot with a single atomic fetch-add;
dumpToFd() reads the preallocated entries directly and writes them with
write(2) only, looping on EINTR/short writes. Accepted tradeoff: at most
one entry can be read torn if a crash lands mid-append into that exact
slot -- documented in logring.h, and the alternative (a seqlock to
detect and retry) wasn't judged worth the complexity for that window.
Other invariants implemented per the discussion:
- sigaltstack with a static 64 KiB buffer, SA_ONSTACK -- a stack-
overflow SIGSEGV has no usable stack for a handler without one.
- Nothing under the actual handler touches Qt, QString or the
allocator: the dump path and a small header (version/git/OS/Qt) are
precomputed into fixed char buffers by install(), which runs once at
startup in normal context.
- Atomic test-and-set so only the first crash writes a dump; a second
concurrent/nested fault goes straight to restore-and-re-raise.
- After writing, the handler restores SIG_DFL and re-raises (POSIX) /
returns EXCEPTION_CONTINUE_SEARCH (Windows) so the OS's own crash
path -- core dump, Windows Error Reporting -- still runs. A handler
that "fixed" the crash by swallowing the signal would destroy exactly
the post-mortem evidence this whole design exists to preserve.
Tested in this environment: POSIX/Linux only, all five signals. Sent
each directly to a running process and confirmed (a) crash_dump.log is
written with the correct header and ring contents, mode 0600, and (b)
the process still terminates via the signal with the kernel's own
"core dumped" flag set (exit code 128+signal, confirmed for all five).
The Windows path is implemented per the discussion's guidance but is
untested -- no Windows build available in this sandbox.
## Step 5 -- getting the data back out
- QETApp::checkCrashDump(), called from checkBackupFiles() only when
there's no stale project file to recover this run (so the two
prompts never both show, per the discussion), offers an unretrieved
crash dump via DiagnosticsReportDialog and then deletes it regardless
of the user's choice -- offered exactly once.
- A new "Aide > Enregistrer un rapport de diagnostic..." action
(QETMainWindow) builds the same kind of report from the *current*
session (QetLogger::buildDiagnosticsReport(): header + this session's
log file) for a manual "attach this to a bug report" flow, not tied
to a crash.
- Both go through QetLogger::redact() before ever reaching the user:
the one redaction implemented is a literal replace of the home
directory with "~", since an absolute path under it leaks the
account name. The discussion's fancier "optionally redact project
filenames too" isn't attempted -- reliably telling a project path
apart from arbitrary log text is a much fuzzier problem than a
literal prefix match.
- DiagnosticsReportDialog shows the full (already-redacted) content
before saving, per the discussion: "the user is about to attach this
to a public tracker."
Verified in a real GUI session (Xvfb): triggered a SIGSEGV, relaunched,
confirmed the crash-report dialog appears with the right header/content,
confirmed it does not reappear on a second relaunch, and confirmed the
manual "Save report" action produces a correctly-formatted report and
saves it to a chosen path.
Built clean, no new warnings.
## Build systems
Registered in both: cmake/qet_compilation_vars.cmake, and
qelectrotech.pro. The .pro needed explicit globs for the new
sources/logging/ui/ subfolder -- sources/logging/*.{h,cpp} was already
globbed, but unlike the other ui/ subfolders that one had no entry of
its own, so diagnosticsreportdialog.{h,cpp} would not have been built
under qmake.
Root cause (see issue #218 discussion):
- QETApp::eventFiltrer (Q_OS_DARWIN) was correct in intent but never
actually installed as an event filter anywhere, and its name didn't
match the QObject::eventFilter virtual signature, so even if it had
been installed it would never have been invoked as an override.
Confirmed dead code.
- main.cpp instead routed Finder's QFileOpenEvent through
MacOSXOpenEvent -> SingleApplication::sendMessage(), which is the
secondary-to-primary IPC channel. Called from within the primary
instance itself, sendMessage() fails silently and the file path is
dropped, which is exactly what double-click does (Finder doesn't spawn
a secondary process, the running instance receives the FileOpen event
directly).
- openFiles() takes a QETArguments, not a QStringList. The dead code's
openFiles(QStringList() << filename) only worked via an untested
implicit QStringList -> QList<QString> -> QETArguments conversion
chain.
Fix:
- Rename eventFiltrer -> eventFilter (qetapp.h/.cpp) so it's a proper
override of QObject::eventFilter, and make it public so main.cpp can
install it on QApplication.
- Build the QETArguments explicitly instead of relying on implicit
conversion.
- main.cpp: drop MacOSXOpenEvent entirely (include + instantiation),
install qetapp as the Q_OS_MACOS event filter on app right after
QETApp qetapp; is constructed and before app.exec(). No race window:
the event loop hasn't started, so no QFileOpenEvent can be delivered
before the filter is installed.
QETArguments::handleFileArgument() already sorts files by extension
(.elmt, titleblock, else project) and openFiles() already fans out to
openProjectFiles()/openElementFiles()/openTitleBlockTemplateFiles()
accordingly, so this single fix covers .qet, .elmt and .titleblock
double-click/drag-to-dock on macOS, not just .qet.
SingleApplication's sendMessage/receivedMessage flow (used for CLI args
on all platforms) is untouched; this only touches the Q_OS_MACOS block,
so there is no behavior change on Windows/Linux.
Follow-up (not included here): the macOS Info.plist (misc/Info.plist)
has an empty CFBundleShortVersionString, which may affect macOS's
willingness to retain file associations across app updates.
- include Liberation-Fonts and osifont
(thanks elevatormind!)
- use "Liberation Sans" as default-font
- adjust License-Tab in About-Form
- Bugfix: When selecting a font, the current
font is highlighted in dialog
- adjust some whitespace and English comments
All export files that are derived from the project (BOM,
nomenclature, etc.) are saved in the same directory by default.
In this context, the standard directories have been grouped
together in qetapp.cpp / qetapp.h so that only one place needs
to be searched for in case of any adjustments.
* terminal_strip:
Terminal strip item can saved / loaded to .qet file
See previous commit...
Move terminal strip drawer class in is own file
Fix wrong use of QStringLiteral and QLatin1String
Double click a TerminalStripItem open the editor
Minor change about checkable QAction of QetDiagramEditor
Minor : corrects a minor aesthetic defect when unbridge terminals
Revamp code
Add and move terminal strip item are now managed by undo command
TerminalStripItem : Draw terminal bridge
Terminal strip item can be added to diagram
Minor : add QGIUtility namespace
the path is set the first time the function is called.
Each other call will immediately return the previously setted path
instead of check again what path to return.
Replace QETApp::diagramInfoKeys() by QETInformation::diagramInfoKeys()
and QETApp::diagramTranslatedInfoKey(str) by
QETInformation::translatedInfoKey(str)
Replace QETApp::conductorInfoKeys() and
QETApp::conductorTranslatedInfoKey(const QString &key) by
QETInformation::conductorInfoKeys() and
QETInformation::translatedInfoKey
Use the function QETInformation::translatedInfoKey(const QString &info)
instead of QETApp::elementTranslatedInfoKey(const QString &info).
The final goal is to remove all information from the QETApp and use
instea QETInformation who is dedicated to this
and a text width by default for new dynamic text, it work also in
element editor command.
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@5568 bfdf4180-ca20-0410-9c96-a3a8aa849046
Add variables for common and custom elements collections, to avoid multiple access to QSettings and so reduce the loading of collections.
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@5462 bfdf4180-ca20-0410-9c96-a3a8aa849046
1- QET create a backup file, use to restor the project when a crash occur
2- User can enable and edit autosave.
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@5374 bfdf4180-ca20-0410-9c96-a3a8aa849046
Possiblility to overide defaut settings by adding in QElectroTech.conf
diagramitemsize, diagramitemfont variable, for example:
[General]
diagramitemsize=12
diagramitemfont=droid
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@5163 bfdf4180-ca20-0410-9c96-a3a8aa849046
Remove the management of custom and common elements collection in the class qetapp.
git-svn-id: svn+ssh://svn.tuxfamily.org/svnroot/qet/qet/trunk@4529 bfdf4180-ca20-0410-9c96-a3a8aa849046
ispyisail