Several problems with glabels-3-batch

[ariep]

Hi, I'm trying to run glabels-3-batch to create a pdf file from a template and csv file, contents added at the end.

Printing to a pdf file from the glabels gui (version 3.4.0 from my laptop, amd64 with gentoo) works, and gives the expected result: text "abc" centered horizontally and vertically. However, running glabels-3-batch -i input.csv -o output.pdf text.glabels

1. on my laptop with glabels-3.4.0: gives a segfault;
2. on my server (raspberry pi with debian jessie) with glabels 3.0.1: produces a pdf, but the text is not aligned vertically (way too high, like there's a newline rendered in the text);
3. on my server with glabels 3.4.0 compiled from source: command doesn't finish, taking 100% cpu and steadily increasing memory usage.

I'm not sure if there's something wrong with my input files or that these are various problems with glabels, any idea?

text.glabels (unzipped):

<?xml version="1.0"?>
<Glabels-document xmlns="http://glabels.org/xmlns/3.0/">
  <Template brand="Dymo" part="11355" size="Other" width="19mm" height="51mm" description="Return Address Labels">
    <Meta category="label"/>
    <Meta category="mail"/>
    <Label-rectangle id="0" width="19mm" height="51mm" round="0mm" x_waste="0mm" y_waste="0mm">
      <Markup-margin size="0mm"/>
      <Layout nx="1" ny="1" x0="0mm" y0="0mm" dx="19mm" dy="51mm"/>
    </Label-rectangle>
  </Template>
  <Objects id="0" rotate="True">
    <Object-text x="3.20644mm" y="2.79399mm" w="44.5871mm" h="13.412mm" justify="Center" valign="Center" auto_shrink="False" a0="1" a1="0" a2="0" a3="1" a4="0" a5="0">
      <Span color="0x000000ff" font_family="Sans" font_size="14" font_weight="Regular" font_italic="False" line_spacing="1">
        <Field name="text"/>
      </Span>
    </Object-text>
  </Objects>
  <Merge type="Text/Comma/Line1Keys" src="/home/arie/labels/input.csv"/>
  <Data/>
</Glabels-document>

input.csv:

text
abc

[jimevins]

Can you try building from the latest on either the master or glabels-3_4 branch. I believe this was fixed a while back.

[ariep]

Thanks for the quick response!

I tried compiling the master branch. I had trouble getting autoconf to work, so I took a shortcut and copied some generated files (configure, depcomp, and various Makefile.ins) from the 3.4.0 release into the master branch instead – no idea if there are changes between the two that may make that go wrong.

After that, ./configure, make and sudo make install. The new program has the same behaviour as the latest release, unfortunately:

$ glabels-3-batch -i input.csv -o output-rpi-master.pdf text.glabels 
LibGlabels-Message: Duplicate template: Dymo 11355.
LABEL FILE = text.glabels

I let it run for two minutes, during which memory use steadily climbs, I killed it after that time.

[jimevins]

I am not sure what is going on. I cut&pasted your two files, ran glabels-batch exactly as you ran it above -- it works as expected:

output-batch.pdf

I am using the head of the glabels_3_4 branch.

[ariep]

Hm, I wonder what the difference could be. Debian jessie is rather old of course, and it's a headless server, so maybe some libraries or dependencies are either missing or too old.

What would be the best way to get some debugging output, so we can see where the program enters its endless loop?

Also, I'd like to exclude anything caused by my half-baked build procedure. I tried building the latest master on a more modern desktop machine, but when I run autoreconf --install (is that even the right command? I couldn't find documentation on that in glabels), I get:

libtoolize: putting auxiliary files in '.'.                                                                                                                                                                                                                                                                                                                               
libtoolize: copying file './ltmain.sh'                                                                                                                                                                                                                                                                                                                                    
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,                                                                                                                                                                                                                                                                                                 
libtoolize: and rerunning libtoolize and aclocal.                                                                                                                                                                                                                                                                                                                         
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.                                                                                                                                                                                                                                                                                                    
configure.ac:24: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.  For more info, see:                                                                                                                                                                                                                                                           
configure.ac:24: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation                                                                                                                                                                                                                                                  
configure.ac:35: installing './compile'                                                                                                                                                                                                                                                                                                                                   
configure.ac:35: installing './config.guess'                                                                                                                                                                                                                                                                                                                              
configure.ac:35: installing './config.sub'                                                                                                                                                                                                                                                                                                                                
configure.ac:24: installing './install-sh'                                                                                                                                                                                                                                                                                                                                
configure.ac:24: installing './missing'                                                                                                                                                                                                                                                                                                                                   
Makefile.am: installing './INSTALL'                                                                                                                                                                                                                                                                                                                                       
automake-1.15: error: cannot open < gtk-doc.make: No such file or directory                                                                                                                                                                                                                                                                                               
autoreconf-2.69: automake failed with exit status: 1

The gtk-doc package is installed, if that's relevant.

[sur5r]

gLabels 3.4.0-2 builds just fine in a jessie environment. Assuming you don't have sbuild or pbuilder in place:

1. apt-get install devscripts
2. dget -x http://deb.debian.org/debian/pool/main/g/glabels/glabels_3.4.0-2.dsc
3. cd glabels-3.4.0
4. Install build dependencies: apt-get install autotools-dev autoconf-archive cdbs intltool gnome-doc-utils gtk-doc-tools yelp-tools libglib2.0-dev libgtk-3-dev libxml2-dev librsvg2-dev libcairo2-dev libpango1.0-dev libebook1.2-dev barcode libqrencode-dev libiec16022-dev
5. dpkg-buildpackage -B

[ariep]

Thanks. I managed to build and install a glabels-3.4.0-2 Debian package (I needed to do glabels-data first). That exhibits the same problem as the one I built from master source: its glabels-3-batch with my inputs keeps eating cpu and memory, not producing any pdf output.

[sur5r]

I just tried your example with 3.4.0-2 both on buster and jessie. It created a PDF just fine in both cases.

[ariep]

Thanks for trying, that further restricts the possible causes. Maybe it's the architecture then (raspberry pi, armhf), or the fact that it's a headless server missing some runtime component that glabels-3-batch depends on?

Is there a way to get debug output, so I can see what the program is trying to do when it hangs? I'll try running it under strace as well.

[ariep]

Here is some strace output of a hanging run. It first loads lots of libraries, templates and font files (I'm wondering why it tries to load so many template files by the way, when it has been given a template file to work with on the command line). Then:

[…]
gettimeofday({1522398409, 961034}, NULL) = 0
futex(0x762dbca0, FUTEX_WAKE, 2147483647) = 0
futex(0x762dbca0, FUTEX_WAKE, 2147483647) = 0
futex(0x762dbca0, FUTEX_WAKE, 2147483647) = 0
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 3
read(3, "\3008\16\233\204\10[Q;Y\262\32\254T\242%", 16) = 16
close(3)                                = 0
futex(0x762dbca0, FUTEX_WAKE, 2147483647) = 0
open("/home/arie/labels/input.csv", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x72e80000
read(3, "text\nabc", 4096)              = 8
read(3, "", 4096)                       = 0
read(3, "", 4096)                       = 0
read(3, "", 4096)                       = 0
read(3, "", 4096)                       = 0
read(3, "", 4096)                       = 0
read(3, "", 4096)                       = 0
[…]

And the read calls continue indefinitely.

It seems that it's trying to read more from the input file than available, for some reason.

(For this particular call, I used an input csv file without trailing newline. I also tried with single trailing newline, and an extra empty line at the end. That doesn't matter for the result.)

[jimevins]

O.k. so we are continuously trying to read data even though the system read is telling us that it just read zero bytes. Unfortunately this part of the code is not instrumented well enough to see what is actually going on.

If you are ok with modifying source, can you do something like

 printf( "c = %d\n", c);

after the line

c=gl_getc (merge_text);

in the file src/merge-text.c? You should see something like:

c = 116
c = 101
c = 120
c = 116
c = 13
c = 97
c = 98
c = 99
c = -1

The -1 should terminate the reading. My guess is that somehow an architectural difference is causing the -1 to be interpreted as something else. This is usually due to missing prototypes or improper casts. It's also possible that the encoding detection code is messing up somehow.

[ariep]

Output from that:

LABEL FILE = text.glabels
c = 116
c = 101
c = 120
c = 116
c = 10
c = 97
c = 98
c = 99
c = 10
c = 10
c = 255
c = 255
c = 255
[…]

the last lines keep repeating of course.

[jimevins]

That did it! Change the following

static gchar
gl_getc(glMergeText *merge_text) {

to

static gint
gl_getc(glMergeText *merge_text) {

At some point, getc was wrapped by the function gl_getc which returned char instead of int. This didn't cause any problems on Intel platforms since char is signed by default. However, on ARM char is unsigned by default, thus causing the EOF (-1) to be interpreted as 255.

[sur5r]

This is great news. Do you think this plus the other commits on glabels-3_4 justify a 3.4.1 release?

[ariep]

Indeed, that makes it work. Thanks a lot!

It's taking rather a long time (13 seconds) to produce a single pdf, but I'll make a separate issue for that.