Re: [lmi] "Not enough room for even the first column" messagebox

[Vadim Zeitlin]

On Thu, 2 May 2019 01:20:24 +0000 Greg Chicares <address@hidden> wrote:

GC> The reason I was running the census described here:
GC>   https://lists.nongnu.org/archive/html/lmi/2019-05/msg00002.html
GC> is that the end user saw this messagebox:
GC>   Not enough room for even the first column.
GC>   [report_table.cpp : 132]
GC> when trying to do
GC>   Census | Print case to PDF

 Please see the bottom of this message for my hypothesis about why this
happens and the suggestion for fixing it.

GC> I checked to see whether I could reproduce the problem more
GC> easily by doing
GC>   Census | Run cell
GC>   File | Print to PDF
GC> but that produced a different messagebox:
GC>   Assertion 'height <= get_total_height() - y' failed.
GC>   [pdf_writer_wx.cpp : 338]

 It would be really useful to have information about the current page when
this assertion fails, but unfortunately it's inaccessible at this level. I
wonder if we should consider adding try/catch statements around the calls
to output_html() to add this information to the error messages. Or maybe we
should pass the page name/identifier to pdf_writer::next_page() and use
this in pdf_writer diagnostic messages?

GC> Because it's so much faster to run this case with x86_64-*-gcc-8.x,
GC> I added some debugging code and rebuilt. The second messagebox
GC> turned out to be a dogs-in-orbit issue:
GC> 
GC> [install_msw.sh]
GC> for z in company_logo.png group_quote_banner.png ;
GC>   do cp --archive /opt/lmi/src/lmi/gwc/$z /opt/lmi/data/ ;
GC> done
GC> 
GC> That recently-added command unconditionally copies public PNG
GC> files, to prevent problems with a brand-new installation. It
GC> would be better to install proprietary files if available,
GC> though, because the 'company_logo.png' with Ugolyok and
GC> Veterok is larger. But any random person who builds lmi from
GC> the savannah site alone should get a working system; would it
GC> be possible to resize that file dynamically if it is larger
GC> than the maximum size implicit in our PDF generation?

 Of course it would, but I wonder how/why is it preferable to just resizing
(or cropping) these files statically? I assume we know the maximum size, as
it's the size used by the proprietary logo, so it doesn't seem necessary to
do it dynamically, does it? The only thing I'd consider doing in the code
would be to check that the logo is not too big.


GC> The original problem isn't solved by copying proprietary PNG
GC> files from a production release. Here's the code I added
GC> (for both issues):
[...snip reasonably looking debugging code...]

GC> I rebuilt with that patch, using 32-bit gcc-8.x, and tried this:
GC>   Census | Run case
GC>   File | Print to PDF
GC> which is like the "Run case to PDF" command in the end-user report,
GC> but omits creating a PDF file for each individual cell (the only
GC> PDF will be for the composite of all cells). It crashed thus:
GC> 
GC>   Unhandled exception: page fault on read access to 0x00000018 in 32-bit 
code (0x00869292).

 Unfortunately this is not really useful without symbols and debugger...

GC> Anyway, I rebuilt with x86_86 instead, and it still crashed.
                           ^^^^^^
 Just for the record, as it confused me for a moment, this was certainly
supposed to be "x86_64".

GC> I modified the patch as follows:
[...]
GC> and rebuilt with 64-bit gcc-8. This time I get:
GC> 
GC>   BIG TROUBLE
GC>   576 max_table_width
GC>   14 desired_margin
GC>   3 minimum_margin
GC>   0 cardinality
GC>   0 data_width

 AFAICS this can only happen if standard_supplemental_report is used, but
there are no columns in it. And looking at the code, it doesn't seem to be
impossible that this is what happens, i.e. I don't see what prevents
SupplementalReport from being 1, but all SupplementalReportColumnsNamesN
from being set to "[none]". If this is indeed what happens, we need to
add some logic for setting SupplementalReport to 0 if no supplemental
report columns are actually specified. Unfortunately I don't know what
would be the best place to do it and while it could be done in
pdf_command_wx.cpp (please let me know if you'd like me to do it), I'm
almost sure that this is not the ideal place for this. Would you have a
better idea?


GC> If I can't figure it out myself (tomorrow), I'll purge all "personally
GC> identifiable information" from the census and share it, or try to create
GC> a minimal test case that fails similarly.

 This would still be very useful, even if the hypothesis above turns out to
be correct, of course (and even more so otherwise).

 Thanks in advance,
VZ