(lifted from here: http://forums.freebsd.org/showthread.php?t=5871) multimedia/pwcbsd has been recently updated to accommodate the changes to graphics/jpeg. This change was only to reference the new jpeg library version in the Makefile, no code was modified. While this has fixed the port in terms of building, it appears to have left pwcbsd (via pwcview) incapable of generating static images (presumably streaming video is unaffected since I don't see any other reports of problems here). Prior to the update pwcview (cmdline tool supplied by pwcbsd) has worked perfectly for several months on my system. I applied the jpeg update a couple of days ago as per /usr/ports/UPDATING. It triggered rebuilds of stamp, php5-gd, and pwcbsd. All built correctly. I have manually re-installed the new kernel module and even rebooted the system to make sure no old processes were hanging about. Following discussion oh the forum I also performed 'portupgrade -rfR jpeg' which rebuilt all 78 packages related to libjpeg. During boot the kernel module loads: Jul 30 12:41:19 calvin kernel: pwc0: <vendor 0x0471 product 0x0311, class 0/0, rev 1.10/0.01, addr 2> on uhub1 Jul 30 12:41:19 calvin kernel: pwc0: vendor 0x0471 product 0x0311, rev 1.10/0.01, addr 2 Jul 30 12:41:19 calvin kernel: pwc0: Philips PCVC740K (ToUCam Pro)/PCVC840 (ToUCam II) USB webcam Jul 30 12:41:19 calvin kernel: pwc0: This camera is equipped with a Sony CCD sensor + TDA8787 (32) Running: pwcview -h -s vga -c 1 -o capture.jpg generates: Webcam set to: 640x480 (vga) at 5 fps Segmentation fault (core dumped) It also generates an image which is viewable, but corrupted. It appears to be truncated & lacks some image and color data. You can see the effects here: http://webcam.easytarget.me.uk/webcam.jpg I'm guessing this must be due to changes in the jpeg libraries, and possibly the bug is with jpeg-7 and not pwcview.. I'm no coder and can't debug this myself, but I am very willing to try any patches or other suggest1ions. I can supply a corefile but I guess that also needs debugging symbols etc.. and I'm not sure how I would generate that.. I have also tried this command using other options, eg. -s for all the available resolutions, -q to change the compression quality. I also tried -y although I don't think this is relevant for static images. Searching on the web did not turn up anything similar being reported elsewhere. How-To-Repeat: # pwcview -h -c 1 - on a my system with my webcam attached.. Have not been able to verify if it also fails with other webcams or usb chipsets.
Responsible Changed From-To: freebsd-ports-bugs->dinoex Over to maintainer of graphics/jpeg, but perhaps this should be lme's PR instead.
State Changed From-To: open->feedback There is one issue known, the scaling API ob libjpeg has changed. But this seemms not the problem here. The new jpeg libs generates smaller images. But the application should not rely on the bytes in the file. Newer files should still be readbale by older libjpeg. Can you get a backtraces of the application which dumps core? Does it crash inside of lipjpeg? in this case you may try to remove: /usr/ports/graphics/jpeg/files/patch-jpegtran.c /usr/ports/graphics/jpeg/files/patch-rdjpgcom.c /usr/ports/graphics/jpeg/files/patch-transupp.c /usr/ports/graphics/jpeg/files/patch-transupp.h Then rebuild jpeg: cd /usr/ports/graphics/jpeg && make clean deinstall install And test again.
Sorry for slow response, family and vacations not leaving much free time for this stuff. I removed the four patch-... files you as described in libjpeg, made clean and reinstalled. I also made clean and reinstalled pwcbsd after that. Unfortunately it still cores out. I verified that the error occurs when pwcview is calling libjpeg: - I determined this by annotating the pwcview sourcecode with some debug statements and then running it to see which call broke. - In the function 'jpeg_write' in pwcview.c I added the following to the loop that writes the jpeg data (line 840) fprintf(stderr,"OWENSDEBUG: jpeg_start_compress called\n"); jpeg_start_compress(cinfo, TRUE); for (i = 0;i < height-2*DCTSIZE;i += 2*DCTSIZE) { fprintf(stderr,"OWENSDEBUG: jpeg_write_raw_data called : height=%i : ",i); jpeg_write_raw_data(cinfo, jdata, 2*DCTSIZE); fprintf(stderr,"returned.\n"); jdata[0] += 2*DCTSIZE; jdata[1] += DCTSIZE; jdata[2] += DCTSIZE; } This results in the output: # ./work/pwcbsd/pwcview -h -s vga -c 1 Webcam set to: 640x480 (vga) at 5 fps OWENSDEBUG: jpeg_start_compress called OWENSDEBUG: jpeg_write_raw_data called : height=0 : returned. OWENSDEBUG: jpeg_write_raw_data called : height=16 : returned. OWENSDEBUG: jpeg_write_raw_data called : height=32 : returned. etc... OWENSDEBUG: jpeg_write_raw_data called : height=448 : returned. OWENSDEBUG: jpeg_write_raw_data called : height=464 : Segmentation fault (core dumped) So.. I decided to try and get a trace as per you suggestion; This was really pushing my skills so apologies, I'm not a developer, just enthusiastic amateur and professional unix sysadmin. Please bear with me if I'm getting it wrong here.. I made clean libjpeg and pwcbsd, then did a 'make extract' in them, hacked the Makefiles in the extracted workdir to add the -g flag to the compiler opts (libjpeg) or command line (pwcview). Then rebuilt, deinstalled and reinstalled. (Note: this is still with the four above mentioned patch-... files removed in libjpeg.) Running gdb on the resultant executable and core gives: calvin# gdb /usr/local/bin/pwcview pwcview.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `pwcview'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libSDL-1.2.so.11...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSDL-1.2.so.11 Reading symbols from /usr/local/lib/libjpeg.so.10...done. Loaded symbols for /usr/local/lib/libjpeg.so.10 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/lib/libvgl.so.5...done. Loaded symbols for /usr/lib/libvgl.so.5 Reading symbols from /usr/local/lib/libaa.so.1...done. Loaded symbols for /usr/local/lib/libaa.so.1 Reading symbols from /lib/libncurses.so.7...done. Loaded symbols for /lib/libncurses.so.7 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libX11.so.6...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libxcb.so.2...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/local/lib/libXau.so.6...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/lib/librpcsvc.so.4...done. Loaded symbols for /usr/lib/librpcsvc.so.4 Reading symbols from /usr/lib/libusbhid.so.3...done. Loaded symbols for /usr/lib/libusbhid.so.3 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 jpeg_fdct_16x16 (data=0xbfbfe350, sample_data=0x28578ee0, start_col=0) at jfdctint.c:2188 2188 jfdctint.c: No such file or directory. in jfdctint.c [New Thread 0x28501040 (LWP 100132)] (gdb) bt #0 jpeg_fdct_16x16 (data=0xbfbfe350, sample_data=0x28578ee0, start_col=0) at jfdctint.c:2188 #1 0x280ecfdc in forward_DCT (cinfo=0xbfbfe9ec, compptr=0x285770bc, sample_data=0x28578ee0, coef_blocks=0x2857ea8c, start_row=0, start_col=0, num_blocks=1) at jcdctmgr.c:82 #2 0x280ec5dc in compress_data (cinfo=0xbfbfe9ec, input_buf=0xbfbfe910) at jccoefct.c:180 #3 0x280ea601 in jpeg_write_raw_data (cinfo=0xbfbfe9ec, data=0xbfbfe910, num_lines=16) at jcapistd.c:153 #4 0x0804b420 in ?? () #5 0xbfbfe9ec in ?? () #6 0xbfbfe910 in ?? () #7 0x00000010 in ?? () #8 0x2822b4e0 in __tsd_lock () from /lib/libc.so.7 #9 0x0805ab48 in ?? () #10 0x00000001 in ?? () #11 0xbfbfe528 in ?? () #12 0x4a8ab3dc in ?? () #13 0x706d742f in ?? () #14 0x3030322f in ?? () #15 0x31383039 in ?? () #16 0x35353138 in ?? () #17 0x2e363539 in ?? () #18 0x0067706a in ?? () #19 0xbfbfe9c8 in ?? () #20 0x28193487 in _malloc_postfork () from /lib/libc.so.7 #21 0x0804ce03 in ?? () #22 0x000001e0 in ?? () .... I'm not including the next 10 pages of O/P, is it signifagent? not sure.. .... #1244 0x00000000 in ?? () #1245 0x00000000 in ?? () #1246 0x102454ff in ?? () #1247 0x2024448d in ?? () #1248 0x5440f750 in ?? () #1249 0x00020000 in ?? () #1250 0x688e0375 in ?? () #1251 0x01a1b814 in ?? () #1252 0xcd500000 in ?? () #1253 0x90feeb80 in ?? () #1254 0x102454ff in ?? () #1255 0x1424448d in ?? () #1256 0x5440f750 in ?? () #1257 0x00020000 in ?? () #1258 0x688e0375 in ?? () #1259 0x0158b814 in ?? () #1260 0xcd500000 in ?? () #1261 0x90feeb80 in ?? () #1262 0xbfbfed00 in ?? () #1263 0x00000006 in ?? () #1264 0xbfbfed1c in ?? () #1265 0x00000016 in ?? () Cannot access memory at address 0xbfc00000 (gdb) I can see the (no debugging symbols found) note in the gdb startup, but also see some symbols there too. If I need to do something smarter for the backtrace please enlighten me :-)
At the suggestion of Dirk Meyer I tried the following in gdb: > could you type at the debugger prompt: > p *(struct jpeg_compress_struct *)0xbfbfe9ec Sure can.. (gdb) p *(struct jpeg_compress_struct *)0xbfbfe9ec $1 = {err = 0xbfbfe968, mem = 0x28576040, progress = 0x0, client_data = 0x28050519, is_decompressor = 0, global_state = 102, dest = 0x285778ec, image_width = 640, image_height = 480, input_components = 3, in_color_space = JCS_YCbCr, input_gamma = 1, scale_num = 1, scale_denom = 1, jpeg_width = 640, jpeg_height = 480, data_precision = 8, num_components = 3, jpeg_color_space = JCS_YCbCr, comp_info = 0x2857700c, quant_tbl_ptrs = {0x2857737c, 0x28577404, 0x0, 0x0}, q_scale_factor = {100, 100, 100, 100}, dc_huff_tbl_ptrs = { 0x2857748c, 0x285776bc, 0x0, 0x0}, ac_huff_tbl_ptrs = {0x285775a4, 0x285777d4, 0x0, 0x0}, arith_dc_L = '\0' <repeats 15 times>, arith_dc_U = '\001' <repeats 16 times>, arith_ac_K = '\005' <repeats 16 times>, num_scans = 1, scan_info = 0x0, raw_data_in = 1, arith_code = 0, optimize_coding = 0, CCIR601_sampling = 0, do_fancy_downsampling = 1, smoothing_factor = 0, dct_method = JDCT_ISLOW, restart_interval = 0, restart_in_rows = 0, write_JFIF_header = 1, JFIF_major_version = 1 '\001', JFIF_minor_version = 1 '\001', density_unit = 0 '\0', X_density = 1, Y_density = 1, write_Adobe_marker = 0, next_scanline = 464, progressive_mode = 0, max_h_samp_factor = 2, max_v_samp_factor = 2, min_DCT_h_scaled_size = 8, min_DCT_v_scaled_size = 8, total_iMCU_rows = 30, comps_in_scan = 3, cur_comp_info = {0x2857700c, 0x28577064, 0x285770bc, 0x0}, MCUs_per_row = 40, MCU_rows_in_scan = 30, blocks_in_MCU = 6, MCU_membership = {0, 0, 0, 0, 1, 2, 0, 0, 0, 0}, Ss = 0, Se = 63, Ah = 0, Al = 0, master = 0x2857a00c, main = 0x2857a1ec, prep = 0x0, coef = 0x2857a184, marker = 0x2857a22c, cconvert = 0x0, downsample = 0x0, fdct = 0x2857a034, entropy = 0x2857a0d4, script_space = 0x0, script_space_size = 0} (gdb) Maybe this means more to others than it does to me, I have time to work on this again now, but just don't know what to do. I am more than happy to try tests/patches suggested by those with developer skills though. ---------------------------------------------- - Owen Carter - http://easytarget.org/
I can confirm the bug with another USB camera: Oct 1 23:44:18 streamer kernel: pwc0 on uhub1 Oct 1 23:44:18 streamer kernel: pwc0: vendor 0x046d product 0x08b0, rev 1.10/0.00, addr 2 Oct 1 23:44:18 streamer kernel: pwc0: Logitech QuickCam Pro 3000 USB webcam Oct 1 23:44:18 streamer kernel: pwc0: This camera is equipped with a Sony CCD sensor + DA8787 (32) having compiled jpeg and pwcview with -g gives me the following on gdb: Starting program: /usr/local/bin/pwcview -h -c 1 -o bla.jpg (no debugging symbols found)...[New LWP 100208] [New Thread 0x28401040 (LWP 100208)] Webcam set to: 320x240 (sif) at 5 fps Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x28401040 (LWP 100208)] 0x2810c64e in jpeg_fdct_16x16 (data=0xbfbfdf28, sample_data=0x28424f60, start_col=0) at jfdctint.c:2188 2188 jfdctint.c: No such file or directory. in jfdctint.c (gdb) where #0 0x2810c64e in jpeg_fdct_16x16 (data=0xbfbfdf28, sample_data=0x28424f60, start_col=0) at jfdctint.c:2188 #1 0x280eecf6 in forward_DCT (cinfo=0xbfbfe5ec, compptr=0x284230bc, sample_data=0x28424f60, coef_blocks=0x2842528c, start_row=0, start_col=0, num_blocks=1) at jcdctmgr.c:82 #2 0x280ed98e in compress_data (cinfo=0xbfbfe5ec, input_buf=0xbfbfe510) at jccoefct.c:180 #3 0x280eb9e9 in jpeg_write_raw_data (cinfo=0xbfbfe5ec, data=0xbfbfe510, num_lines=16) at jcapistd.c:153 #4 0x0804b430 in jpeg_write () #5 0x0804ce13 in main () (gdb) p *(struct jpeg_compress_struct *)0xbfbfdf28 $2 = {err = 0xffffff90, mem = 0x2d, progress = 0x2, client_data = 0xffffffdc, is_decompressor = 30, global_state = 4, dest = 0xffffffe2, image_width = 26, image_height = 4294967136, input_components = 1, in_color_space = JCS_UNKNOWN, input_gamma = 6.5781869509053998e-313, scale_num = 4294967289, scale_denom = 4294967263, jpeg_width = 31, jpeg_height = 4294967140, data_precision = 24, num_components = -1, jpeg_color_space = 4294967295, comp_info = 0xfffffffb, quant_tbl_ptrs = { 0xfffffff9, 0x1b, 0xffffffed, 0xffffff64}, q_scale_factor = {52, -60, 33, 1}, dc_huff_tbl_ptrs = {0x2, 0xffffffe7, 0x11, 0xffffff6c}, ac_huff_tbl_ptrs = {0x1d, 0xffffffdf, 0x26, 0xffffffe0}, arith_dc_L = "\t\000\000\000\r\000\000\000ñÿÿÿlÿÿÿ", arith_dc_U = "\035\000\000\000ßÿÿÿ&\000\000\000àÿÿÿ", arith_ac_K = "\t\000\000\000\r\000\000\000ñÿÿÿ(ÿÿÿ", num_scans = 92, scan_info = 0xffffffe4, raw_data_in = -6, arith_code = -6, optimize_coding = 27, CCIR601_sampling = -24, do_fancy_downsampling = -1, smoothing_factor = -160, dct_method = 45, restart_interval = 4294967261, restart_in_rows = 15, write_JFIF_header = -6, JFIF_major_version = 23 '\027', JFIF_minor_version = 0 '\0', density_unit = 0 '\0', X_density = 65501, Y_density = 65535, write_Adobe_marker = 11, next_scanline = 675467316, progressive_mode = 672187936, max_h_samp_factor = 675468108, max_v_samp_factor = 0, min_DCT_h_scaled_size = -1077944136, min_DCT_v_scaled_size = 672061838, total_iMCU_rows = 3217024492, comps_in_scan = 675426492, cur_comp_info = {0x28424f60, 0x2842528c, 0x0, 0x0}, MCUs_per_row = 1, MCU_rows_in_scan = 672082898, blocks_in_MCU = -1077942804, MCU_membership = {0, 1, 1, 1, 675426492, 675467652, 0, 19, 14, 5}, Ss = 672084133, Se = 2, Ah = 0, Al = 0, master = 0x1, main = 0x0, prep = 0x0, coef = 0x284230bc, marker = 0x280eec90, cconvert = 0x140, downsample = 0x2821f990, fdct = 0xbfbfe0e8, entropy = 0x280eb9e9, script_space = 0xbfbfe5ec, script_space_size = -1077943024} (gdb) line 2188 in jfdctint.c: tmp0 = GETJSAMPLE(elemptr[0]) + GETJSAMPLE(elemptr[15]); That's how far I come to. I have no idea how the jpeg code works here, but I guess some API change of the jpeg lib triggers some memory access problems here. Maybe jpeg_write_raw_data() has to be called in a different way, but so far I could not find any jpeg API description so far.
Ok, I think I found the problem. After I found the jpeg API docs in libjpeg.txt I saw this in there: * Set cinfo->raw_data_in to TRUE. (It is set FALSE by jpeg_set_defaults().) This notifies the library that you will be supplying raw data. Furthermore, set cinfo->do_fancy_downsampling to FALSE if you want to use real downsampled data. (It is set TRUE by jpeg_set_defaults().) So I applied this little patch: *** pwcview.c.old Fri Oct 2 14:37:03 2009 --- pwcview.c Fri Oct 2 14:33:35 2009 *************** *** 837,842 **** --- 837,844 ---- jdata[1] = jimage[1]; jdata[2] = jimage[2]; + cinfo->raw_data_in = TRUE; + cinfo->do_fancy_downsampling = FALSE; jpeg_stdio_dest(cinfo, outfile); jpeg_start_compress(cinfo, TRUE); and I get no more coredumps, but valid pictures. Can someone send this to the correct maintainer of pwcbsd ? I don't know how to correctly submit it to the ports. I Cc it to the one mentioned in the Makefile however.
Quoting Ralf Gebhart <gebhart@burdawireless.com>: > Ok, I think I found the problem. > After I found the jpeg API docs in libjpeg.txt I saw this in there: > * Set cinfo->raw_data_in to TRUE. (It is set FALSE by jpeg_set_defaults().) > This notifies the library that you will be supplying raw data. > Furthermore, set cinfo->do_fancy_downsampling to FALSE if you want to use > real downsampled data. (It is set TRUE by jpeg_set_defaults().) > > So I applied this little patch: > > *** pwcview.c.old Fri Oct 2 14:37:03 2009 > --- pwcview.c Fri Oct 2 14:33:35 2009 > *************** > *** 837,842 **** > --- 837,844 ---- > jdata[1] = jimage[1]; > jdata[2] = jimage[2]; > > + cinfo->raw_data_in = TRUE; > + cinfo->do_fancy_downsampling = FALSE; > jpeg_stdio_dest(cinfo, outfile); > jpeg_start_compress(cinfo, TRUE); > > and I get no more coredumps, but valid pictures. > > Can someone send this to the correct maintainer of pwcbsd ? I don't > know how to correctly submit it to the ports. I Cc it to the one > mentioned in the Makefile however. Hi Ralf, thanks for the patch. I'll take a look at it and commit it if it works for me. @Dirk: If the patch is correct, I will close the PR. Cheers Lars -- Lars Engels lme@FreeBSD.org
lme 2009-10-03 18:54:20 UTC FreeBSD ports repository Modified files: multimedia/pwcbsd Makefile Added files: multimedia/pwcbsd/files patch-pwcview.c Log: - Fix pwcview crash when taking still images - Bump PORTREVISION PR: ports/137265 Submitted by: Ralf Gebhart <gebhart (AT) burdawireless.com> Revision Changes Path 1.23 +1 -1 ports/multimedia/pwcbsd/Makefile 1.1 +11 -0 ports/multimedia/pwcbsd/files/patch-pwcview.c (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Responsible Changed From-To: dinoex->lme I'll take it.
State Changed From-To: feedback->closed Committed. Thanks!