Issue 105835 - Improvement program broken in DEV300_m58
Summary: Improvement program broken in DEV300_m58
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m58
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: Olaf Felka
QA Contact: issues@framework
Keywords: regression, usagetracking
Depends on:
Blocks: 99999
  Show dependency tree
Reported: 2009-10-12 17:04 UTC by bjoern.michaelsen
Modified: 2017-05-20 10:29 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description bjoern.michaelsen 2009-10-12 17:04:21 UTC
The Openoffice Improvement Program is broken in DEV300_m58, was fine in DEV300_m57.
The log file only contains binary garbage.

biased guess: Reason is somewhere in oj18, which is huge.

@oj: Do you have a InstSet for oj18 to confirm this? I have had a look at the
changes made, but that cws is huge.
Just guessing one think to check for: Have all URLs passed on to the
UiEventsLogger been passed through XURLTransformer->parseStrict, like they have
been before?
Comment 1 bjoern.michaelsen 2009-10-12 17:08:08 UTC
added usagetracking, regression keywords
Comment 2 ocke.janssen 2009-10-13 07:32:54 UTC
@b_michaelsen: The csv file will be written when the office dies or when the
logger will be disposed. I remember that the cws mhu20 has changed something in
the file world. Perhaps you could ask mav for more information. May be you have
to flush the stream.
Comment 3 ocke.janssen 2009-10-13 12:58:52 UTC
add fma on cc
Comment 4 bjoern.michaelsen 2009-10-13 19:48:29 UTC
Ok, The Improvement program itself is _not_ broken. Logging works.
However, if the logfile (which is open for writing logdata) gets opened (via a
normal file-url dispatch), strange things happen:
- The file show up as having some weird binary content in OOo. However, when
  looking at the file with other tools (stat, cat, vim) the file shows up as
  empty (as expected).
- When the loaded document (however it was imported) gets open, OOo _writes_
  binary garbage into the logfile. This is without ever notifying the user that
  data is changed in the filesystem.

So, as long as the data is not being looked at with OOo while logging,
everything works. All this was tested with the latest fixes for the new buffered
IO introduced with mhu20.

Further investigation showed the following root causes:

- Premature optimization in comphelper::UiEventslogger
  and logging::FileHandler skip flushing because they expect
  osl::File to be unbuffered. Currently nothing calls
  @fs: Should logging::FileHandler::publish() do so, or is this
  client expected to explicitly call flush() on the FileHandler?
- This leaves the logfile as an empty (zero byte) file.
- OOo inappropriately handles zero byte files. If one clicks File->Open
  it shows an import dialog. Even if one presses "Cancel" the file gets
  overridden (with binary garbage/likely an empty storage). The same happens
  when the file is opened and closed (_without_ saving).
  Opening the file read-only fixes this for the usage tracking, but the issue
  is serious enough in itself.
  @mav: Please have a look.

removing oj from cc as this is indeed not related to cws oj18.
Adding mav to cc because of opening empty files issue.
Adding fs to cc because of flush issue in logging::FileHandler.

Should we separate the issues?
Comment 5 bjoern.michaelsen 2009-10-14 11:19:22 UTC
Separated out the zero length file issue as issue 105894 (might be a showstopper
in itself, mav will investigate).

Therefore removing mav from this issue.
Comment 6 bjoern.michaelsen 2009-10-14 12:48:25 UTC
started work in cws oooimprovement5
Comment 7 Frank Schönheit 2009-10-14 13:16:36 UTC
fs->b_michaelsen: sorry for the delay ... I'm somewhat undecided with respect to
"flush". Given that you say nobody currently calls XLogHandler::flush, it might
be a good idea to add this to the publish call, just to catch the other
occurrences where logger clients forgot the flush. On the other hand, it'd be
somewhat hacky, as it would render XLogHandler::flush useless (it's effectively
a no-op then).

Given that the only existing client for XLogHandler::publish currently is the
Logger implementation itself
I tend to think that EventLogger::impl_ts_logEvent_nothrow should not only call
"publish" at each handler, but also "flush". This way, it could be considered an
implementation detail of the Logger implementation that publishing a record also
means flushing all handlers where it was logged to.
Comment 8 uwe.luebbers 2009-10-14 14:50:36 UTC
set target
Comment 9 bjoern.michaelsen 2009-10-14 15:40:38 UTC
fixed in cws oooimprovement5 in revision 276854.

@fs: Could you please review the changes made in extensions/logging?
Comment 10 Frank Schönheit 2009-10-15 07:55:09 UTC
> @fs: Could you please review the changes made in extensions/logging?

Looks fine to me. Thanks for taking *this* road ;-)
Comment 11 bjoern.michaelsen 2009-10-15 19:36:03 UTC
@of: reassigning, please verify
Comment 12 Olaf Felka 2009-10-16 15:19:56 UTC
of: Improvement program gives results and can display them in OOo.