ST_AsText hangs backend

[komzpa]

Trying to get text with precision 40:

 Select ST_AsText('01040000004F0000000101000000244AD52CA286504058F4A4D3AB255140010100000062359967C8556240C56A32CF906B5E40010100000011DA2800CE1B60405A908C4AC1505D400101000000264AD52CA286504059F4A4D3AB255140010100000079E1CE20AB316540E21BBCE547446240010100000040496AF647A85F4031A081A090A36640010100000010DA2800CE9B52402C4846A560A8534001010000006040034121475E4060DBCA04DC2B634001010000009CBFFCBEDEB858409F2435FB23546740010100000079D2FDCC90544A4036F0ED5FDA964F40010100000079D2FDCC9054554035F0ED5FDA96554001010000003E533FDCB333604040102E99DBBC65400101000000EE19A0276FE15640602D7D25154B64400101000000D8F176DFB5276140AFE3EDBE6B0F5C400101000000C0B69509B8575740CF5F7E5F6FDC634001010000000000000000E065400000000000C06240010100000055E103C018095F40ADF001608C0467400101000000E4CAD299530D58403F98951A548557400101000000A3BFFCBEDEB858405EDBCA04DC2B63400101000000B8BB7C33D97E5D4051E8E48F47625B400101000000AF4E6833720C5D403AC4413D17115B4001010000008C4B663885294B406D4AF2FB35274F400101000000A6E153330BE33E4012504F75F3DC474001010000004EC3A76616C65A4048403DD5CD7359400101000000D86BB8A33572434090F27AC2234C4A40010100000062359967C8556240C36A32CF906B5E400101000000AA1EFC3FE7F65740530FFE9F737B634001010000008B4B663885294B406C4AF2FB35274F400101000000D8F176DFB5276140B0E3EDBE6B0F5C400101000000B04E6833F23064403AC4413D178E614001010000008559814798985640C0EFD16624C364400101000000A1DB5D6F204E5C40DE30542AEF6D57400101000000856E77BD817853407AC350A9BCB75240010100000000000000000049400000000000004E4001010000007AD2FDCC9054554036F0ED5FDA9655400101000000A6E153330BE3444025A09EEAE6B94B400101000000E492194E616A56409C92FC7ECD495440010100000042B7BBDE405C5940BD61A854DEDB5540010100000059E103C018095F40540FFE9F737B63400101000000E3CAD299538D65403E98951A54856240010100000045C3A76616C64F4021A09EEAE6B9514001010000007BD2FDCC90D4624036F0ED5FDA9660400101000000FBFFFFFFFF7F5B400000000000C06740010100000009F32F6C480F60409FD282DAEA34664001010000000000000000805640FEFFFFFFFF3F654001010000000AF32F6C480F6040622D7D25154B64400101000000EC78BBEFDA836340EC78BBEFDA636040010100000084598147989856403C102E99DBBC65400101000000A41EFC3FE7F65740AAF001608C0467400101000000846E77BD8178534079C350A9BCB752400101000000465693662F786140633834053B3F5F400101000000000000000040604000000000004065400101000000BF5AFA4A2A96594008F32F6C488F67400101000000A6E153330BE3444024A09EEAE6B94B400101000000EB19A0276FE156409BD282DAEA346640010100000057AFE18ED6C83B401DE5F58447984640010100000042496AF647A85F40D15F7E5F6FDC634001010000007EDFA3CD48865A403D533FDCB3B36740010100000076D2FDCC90544A4032F0ED5FDA964F4001010000000EDA2800CE9B52402B4846A560A85340010100000086DFA3CD48865A40C2ACC0234CCC6240010100000037A505B5D5695D400AF32F6C488F674001010000000000000000405F4000000000000059400101000000CA6BB8A33572434087F27AC2234C4A4001010000007AD2FDCC90544A4035F0ED5FDA964F4001010000003E533FDCB3336040C2EFD16624C3644001010000000000000000003440000000000000444001010000003DA505B5D5695D40F70CD093B7F062400101000000AF4E6833F23064403AC4413D178E614001010000004DC3A76616C64F4024A09EEAE6B9514001010000009B5CA9AE46F35F409B5CA9AE46B359400101000000E292194E616A56409B92FC7ECD4954400101000000C75AFA4A2A965940F60CD093B7F062400101000000BCB69509B85757402DA081A090A36640010100000078205C32B7795C403E533FDCB3B3674001010000005C40034121475E40A22435FB2354674001010000007E205C32B7795C40C2ACC0234CCC624001010000000200000000805B400000000000C06240010100000076BCDD77EDB1644076BCDD77ED916140'::geometry,40);

[komzpa]

39,38,37 kills backend, 36 returns fine.

[komzpa]

ST_AsGeoJSON clamps down to ~13.

[Algunenano]

Seems pretty bad. With the following change to the tests you get a coredump:

diff --git a/liblwgeom/cunit/cu_out_wkt.c b/liblwgeom/cunit/cu_out_wkt.c
index c070efbd5..db502cf2a 100644
--- a/liblwgeom/cunit/cu_out_wkt.c
+++ b/liblwgeom/cunit/cu_out_wkt.c
@@ -52,7 +52,7 @@ static char* cu_wkt(char *wkt, uint8_t variant)
         printf("error converting '%s' to lwgeom\n", wkt);
         exit(0);
     }
-  s = lwgeom_to_wkt(g, variant, 8, NULL);
+  s = lwgeom_to_wkt(g, variant, 36, NULL);
     lwgeom_free(g);
     return s;

#0  0x00007f9686fdbd7f in raise () from /usr/lib/libc.so.6
#1  0x00007f9686fc6672 in abort () from /usr/lib/libc.so.6
#2  0x00007f9686fc6548 in __assert_fail_base.cold.0 () from /usr/lib/libc.so.6
#3  0x00007f9686fd4396 in __assert_fail () from /usr/lib/libc.so.6
#4  0x00007f96875ad1c1 in lwprint_double (d=<optimized out>, maxdd=<optimized out>, 
    buf=0x7ffc95e2ec00 "0.1111", '0' <repeats 13 times>, "430766533554560737", bufsize=38) at lwprint.c:510
#5  0x00007f968759e66a in ptarray_to_wkt_sb (ptarray=<optimized out>, sb=0x55b812ee3200, precision=36, variant=<optimized out>)
    at lwout_wkt.c:112
#6  0x00007f968759cfb2 in lwgeom_to_wkt (geom=0x55b812ee3a10, variant=1 '\001', precision=36, size_out=0x0) at lwout_wkt.c:687
#7  0x000055b812baee38 in cu_wkt (wkt=<optimized out>, variant=1 '\001') at cu_out_wkt.c:55

I guess that char coord[OUT_DOUBLE_BUFFER_SIZE]; doesn't have enough size and should be allocated dynamically.

[pramsey]

It looks like the assertion (why?) in lwprint_double() is causing a fault (at least for me in OSX). I'm not sure why we want to stop in the case that the requested size is larger than the buffer… snprintf has nicely avoided over-writing the ends of the buffer. I guess because we do want to support arbitrarily large precisions in double output? In that case Algunenano's suggestion to increase input buffer size to match requested precision size makes sense (at the expense of allocation, so things will get slower (unless we do the trick of only allocating on the heap when the request is > MAXBUFFERSIZE)

[pramsey]

Continuing on w/ this, unfortunately the caller doesn't really know how big a buffer is required, since the "digits" parameter is about the number of digits after the decimal point, so the actual size of the whole number part is going to determine the how wide a buffer is needed.

Functional question: are arbitrarily large values of digits a required feature, or would just not crapping out in this case, and returning shortened results be acceptable?

Another possibility: just making the static buffer much larger (256 bytes, say) and also removing the assert would provide "reasonable" numbers of digits supported, and get rid of the failure case for assholes who decide they want 512 digits of formatting. I think I like that best.

[pramsey]

In 16716:

Increase double printing buffer, and strip out assertion that buffer is never filled
(References #4165)

[pramsey]

In 16717:

Increase double printing buffer, and strip out assertion that buffer is never filled
(References #4165)