• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-1322
Type: Bug Bug
Status: Fix Pending Fix Pending
Priority: Normal Normal
Assignee: Unassigned
Reporter: Dale Glass
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Crash in OpenJPEG when uploading 16x16 image

Created: 21/Jun/07 01:25 PM   Updated: 04/May/09 11:22 AM
Return to search
Component/s: Crashes, Source Code
Affects Version/s: 1.17.0.x
Fix Version/s: None

File Attachments: 1. File info_fetching2.tga (1 kB)
Environment:
Second Life 1.17.0 (12) Jun 20 2007 01:56:05

You are at 256190.5, 256570.0, 26.5 in Clara located at sim749.agni.lindenlab.com (69.25.105.181:12035)

CPU: Can't get terse CPU information
Memory: 3954 MB
OS Version: Linux 2.6.19-gentoo-r5 #5 SMP Sat Apr 21 21:49:46 CEST 2007 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 7900 GS/PCI/SSE2
OpenGL Version: 2.1.1 NVIDIA 100.14.09
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.10_0000000000)
Packets Lost: 39/18799 (0.2%)
Viewer Digest: f490de5c-d958-da67-462e-0410921c09b2
Issue Links:
Relates

Last Triaged: 26/Mar/09 01:51 PM
Linden Lab Issue ID: DEV-24157
Linden Lab Internal Branch: viewer/viewer_1-23


 Description  « Hide
When uploading a 16x16 texture, the viewer crashes with "LLImageBase::allocateData called with bad dimentions: 0x0x0"
This seems to be a bug in OpenJPEG with handling small images. The same image, when rescaled to 32x32 uploads fine.

Backtrace:

#0 0x0925e64c in LLError::crashAndLoop (message=@0xff94337c)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llcommon/llerror.cpp:1063
#1 0x08eb35fc in errorCallback (error_string=@0xff94337c)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/viewer.cpp:6610
#2 0x0926029c in LLError::Log::flush (out=0x9d55d00, site=@0x9bea400)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llcommon/llerror.cpp:991
#3 0x08fc6e34 in LLImageBase::allocateData (this=0xd017bd0, size=0)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llimage/llimage.cpp:134
#4 0x08fc70f2 in LLImageFormatted::allocateData (this=0xd017bd0, size=-789)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llimage/llimage.cpp:1383
#5 0x08fc3760 in LLImageFormatted::copyData (this=0xd017bd0, data=0x1aa93000 "ÿOÿQ", size=-789)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llimage/llimage.cpp:1428
#6 0x08fd17ac in LLImageJ2COJ::encodeImpl (this=0x14a68770, base=@0xd017bd0, raw_image=@0xceb67c8, comment_text=0x0, encode_time=0)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llimagej2coj/llimagej2coj.cpp:302
#7 0x08fca38a in LLImageJ2C::encode (this=0xd017bd0, raw_imagep=0xceb67c8, comment_text=0x0, encode_time=0)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llimage/llimagej2c.cpp:275
#8 0x08fca3eb in LLImageJ2C::encode (this=0xd017bd0, raw_imagep=0xceb67c8, encode_time=0)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llimage/llimagej2c.cpp:268
#9 0x08ba3ea7 in LLViewerImageList::convertToUploadFile (raw_image=@0xff946f70)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/llviewerimagelist.cpp:1113
#10 0x08ba4372 in LLViewerImageList::createUploadFile (filename=@0x11bd3b20, out_filename=@0xff9573d0, codec=4 '\004')
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/llviewerimagelist.cpp:1088
#11 0x08c37dc3 in upload_new_resource (src_filename=@0x11bd3b20, name=@0xff957640, desc=@0xff957634, compression_info=0,
destination_folder_type=LLAssetType::AT_NONE, inv_type=LLInventoryType::IT_NONE, next_owner_perm=0, display_name=@0x99c1608, callback=0, userdata=0x0)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/llviewermenufile.cpp:537
#12 0x083e8e63 in LLFloaterNameDesc::onBtnOK (userdata=0x11bd38c0)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/llfloaternamedesc.cpp:215
#13 0x0904503b in LLButton::handleMouseUp (this=0xb8629c0, x=70, y=12, mask=0)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llui/llbutton.cpp:360
#14 0x08d24901 in LLViewerWindow::handleMouseUp (this=0x9d477e0, window=0x9e29d80, pos=@0xff957848, mask=0)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/llviewerwindow.cpp:841
#15 0x08f6c70d in LLWindowSDL::gatherInput (this=0x9e29d80)
at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/llwindow/llwindowsdl.cpp:2074
#16 0x08ec303c in check_for_events () at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/viewer.cpp:1775
#17 0x08eccf3b in main_loop () at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/viewer.cpp:1800
#18 0x08ed2176 in main (argc=1, argv=0xff958104) at /home/dale/tmp/home/dale/svk/avatarscanner/indra/i686-linux-client-releasenoopt/newview/viewer.cpp:1704

Debugging the viewer revealed that the crash happens because LLImageBase tries to allocate memory for a 0x0 texture. This happens because the size argument to the function is negative. The function then tries using mWidth and mHeight, which are 0, and crashes.

The size parameter comes from LLImageJ2COJ::encodeImpl, from llimagej2coj/llimagej2coj.cpp line 300:

codestream_length = cio_tell(cio);
base.copyData(cio->buffer, codestream_length);

cio_tell for some reason returns a negative number (-789). According to the OpenJPEG documentation, cio_tell returns the position in a byte stream, where a negative number makes no sense.

The image that causes the crash is attached

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
[ Permlink | « Hide ]
Seg Baphomet added a comment - 26/Jun/07 10:45 AM
Hahaha, I just got nailed by a similar crash last night, only it was with decoding a texture. It was caused by a996abeb-fe86-0e45-8740-a8be3a8b8178, and it was 100% repeatable, I crashed many many times trying to nail what texture it was. Crashed the instant it tried to decode that texture. You'll note the viewer crashes itself on purpose...

Error and stack trace:

2007-06-26T05:10:50Z ERROR: LLImageBase::allocateData called with bad dimentions: 16x16x0

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1105209680 (LWP 2938)]
LLError::crashAndLoop (message=@0x41dffd00) at x86_64-linux-client-release/llcommon/llerror.cpp:1063
1063 *crash = 0;
(gdb) bt
#0 LLError::crashAndLoop (message=@0x41dffd00) at x86_64-linux-client-release/llcommon/llerror.cpp:1063
#1 0x000000000152b331 in LLError::Log::flush (out=<value optimized out>, site=@0x2016d40) at x86_64-linux-client-release/llcommon/llerror.cpp:991
#2 0x00000000012d14b8 in LLImageBase::allocateData (this=0xa06a900, size=0) at x86_64-linux-client-release/llimage/llimage.cpp:134
#3 0x00000000012d1799 in LLImageRaw::allocateData (this=0x41dffd00, size=68893904) at x86_64-linux-client-release/llimage/llimage.cpp:242
#4 0x00000000012cef9b in LLImageRaw::resize (this=0xa06a900, width=16, height=16, components=0 '\0')
at x86_64-linux-client-release/llimage/llimage.cpp:272
#5 0x00000000012de6a8 in LLImageJ2COJ::decodeImpl (this=<value optimized out>, base=<value optimized out>, raw_image=@0xa06a900,
decode_time=<value optimized out>, first_channel=4, max_channel_count=4) at x86_64-linux-client-release/llimagej2coj/llimagej2coj.cpp:169
#6 0x00000000012d6218 in LLImageJ2C::decode (this=0x889b9f0, raw_imagep=0xa06a900, decode_time=0.100000001, first_channel=4, max_channel_count=4)
at x86_64-linux-client-release/llimage/llimagej2c.cpp:248
#7 0x00000000012ddef0 in LLImageWorker::doWork (this=0x64e8c30, param=4) at x86_64-linux-client-release/llimage/llimageworker.cpp:118
#8 0x0000000001556ebf in LLWorkerThread::WorkRequest::processRequest (this=0x587e890)
at x86_64-linux-client-release/llcommon/llworkerthread.cpp:161
#9 0x00000000015376ff in LLQueuedThread::processNextRequest (this=0x2580d60) at x86_64-linux-client-release/llcommon/llqueuedthread.cpp:419
#10 0x00000000015379e0 in LLQueuedThread::run (this=0x2580d60) at x86_64-linux-client-release/llcommon/llqueuedthread.cpp:491
#11 0x000000000154fd69 in LLThread::staticRun (apr_threadp=<value optimized out>, datap=0x41b3cd0)
at x86_64-linux-client-release/llcommon/llthread.cpp:70
#12 0x00000030ebe061c5 in start_thread () from /lib64/libpthread.so.0
#13 0x00000030e9ed062d in clone () from /lib64/libc.so.6


[ Permlink | « Hide ]
Seg Baphomet added a comment - 10/Jul/07 06:07 PM
Please see if the patches at VWR-1475 help, the default codec parameters cause all kinds of strange problems.

I doubt that would help my decode problem though. There may still be a bug lurking in OpenJPEG.


[ Permlink | « Hide ]
Seg Baphomet added a comment - 29/Aug/07 10:05 AM
Hmmm, OpenJPEG is full of a lot of static buffers inside structures, I've been working on making them dynamically allocated. Doing so results in valgrind detecting buffer underruns! With static buffers inside structures, this would mean it may very well be stomping on parts of the structure just before the buffer, and valgrind would never detect it.

"Working on it."


[ Permlink | « Hide ]
Bridie Linden added a comment - 29/Aug/07 04:21 PM
Hoping Seg is indeed "working on it"!
Lindens won't be getting to OpenJPEG issues.

[ Permlink | « Hide ]
Seg Baphomet added a comment - 09/Sep/07 09:37 PM
Status update:

Me and Dale attempted to work on this. He can still reproduce it with the stock Linden library pack.

I tried to reproduce it using SVN rev 447 of OpenJPEG, I am able to upload the image, but it ends up being scaled down to 8x8. So maybe something got fixed, but there's still a bug there.

Dale attempted to update his build to the same SVN rev, but ran into build problems and hasn't got it to work last I heard.

I wasn't able to reproduce my decode bug. I just get a "missing texture". Did the texture disappear or did I fix it?


[ Permlink | « Hide ]
Tofu Linden added a comment - 04/May/09 11:22 AM
openjpeg on all platforms upgraded to v1.3 as of 1.23RC2, where problem doesn't repro.


Powered by Atlassian JIRA the Professional Issue Tracker. (Enterprise Edition, Version: 3.13.2-#335) - Bug/feature request - Atlassian news - Contact Administrators