michaelrsweet
commented
11 months ago So the calculation "(ras-right - ras->left + 7) / 4 + 3" is intended to compute the maximum size needed for compression. When converted to a bitmap, each uncompressed line will be "(ras->right - ras->left + 7) / 8" bytes in length. The PackBits algorithm has a maximum expansion factor of about 1%, so double the uncompressed line length plus 3 should have been more than enough...
The pcl_write_line function uses out_length, so maybe that's what should be used here...
./ipptransform-static -i application/pdf -m application/vnd.hp-pcl -f 123.pcl 123.pdf
DEBUG: page_dict_cb(dict=0x80e8d348, key="ExtGState", outpage=0xbe7e57ac), type=6 DEBUG: page_dict_cb: objval=0x80e8c658(16), arrayval=(nil), dictval=0x80e8d978 DEBUG: page_dict_cb(dict=0x80e8d348, key="Font", outpage=0xbe7e57ac), type=6 DEBUG: page_dict_cb: objval=0x80e8c698(17), arrayval=(nil), dictval=0x80e8dfd0 DEBUG: page_dict_cb(dict=0x80e8d348, key="ProcSet", outpage=0xbe7e57ac), type=1 DEBUG: iwidth=595.28, iheight=841.89, cwidth=559.843, cheight=771.024, rotate=false DEBUG: Opening content stream 1/1... DEBUG: Opened stream 1, resmap[0]=(nil) ATTR: job-impressions=1 ATTR: job-pages=1 ATTR: job-media-sheets=1 DEBUG: Using Poppler version of pdftoppm. DEBUG: Running "/opt/cups/bin/pdftoppm -gray -aa no -r 300 -scale-to 3507 '/tmp/95f681e5.pdf'". double free or corruption (out) Aborted
After debugging, the error was in:
free(line); error.
Continue debugging：
The problem occurs in the pcl_write_line function , which causes comp_buffer overflow。
comp_buffer is malloc in pcl_start_page function:
ras->comp_buffer = malloc((ras->right - ras->left + 7) / 4 + 3);
I don't understand what it means, but after I changed it to “ras->comp_buffer = malloc(ras->right - ras->left ); ”, the error disappeared.