- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
More information:
- This fails only on a dual-Xeon machine.
- Turning UseIPP off after calling CreateDecompress eliminates the problem, so it is clearly something in the IPP code.
We are continuing to try to track this down. It is extremely unclear what might be happening, but it is beginning to look more and more like it is something in the IPP JPEG code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thank you for letting us know about some problems, but could you please provide a bit more information?Specifically, what version of IPP do you use? What operating system? What hardware platform? Did you tried static IPP libraries or you only use DLL?
In your first message you said that fail caused by ippji7 library, which is Itanium specific library. Now you are talking that this fails only on dual-Xeon system.
Is your application use any kind of threading above IPP?
What compiler did you use to produce executable?
I'll be glad to help you as much as I can, but need also some help from you:)
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your reply.
This is being called by the IPP JPEG library from the jdsample.c module. I am not entirely sure what the inputs and outputs are for the function involved. I have been able to establish that neither the input or output point to buffers that were allocated by the application or our JPEG wrapper. Both seem to have been allocated by the JPEG library.
There might be an alignment issue, because it would make sense to be loading 16-byte groups from a 16-byte boundary. Hopefully, I can spend some time with this and try to understand what the input and outputs are for both the undocumented IPP JPEG library function and the IPP library function that is being called. I haven't yet tried to find the documentation for ippiSampleUpRowH2V2_Triangle_JPEG_8u_C1 to see what might be happening with it.
If there is an alignment problem, I'm still a little mystified as to why this only fails as rarely as it does - 16-byte boundary alignments are pretty rare unless you go out of your way to get them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
first of all thanks a lot for such a deep analisys of that problem. Unfortunately it gives no answerabout the reasons for this fault. Of course we tested all IPP functions on all supported architectures and did not face this problem. Could you try to link the same application with IPP static libraries? Another option, if you do not have static libraries, you can try to disable OMP threading by calling ippSetNumThreads(1) somewhere at the beginning of your program?
It should not be alignment problem because in all IPP functions we are trying to process unaligned cases separately.
You also can check the same images with JPEGView sample, which uses the same function and see if the problem is reproducable.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
const DWORD page = 8192;
void* mem = VirtualAlloc(0, page*2, MEM_COMMIT, PAGE_READWRITE);
void* dest = VirtualAlloc(0, page, MEM_COMMIT, PAGE_READWRITE);
void* guard = (char*)mem + page;
DWORD oldAccess;
BOOL ok = VirtualProtect(guard, page, PAGE_NOACCESS, &oldAccess);
IppStatus stat = ippiSampleUpRowH2V2_Triangle_JPEG_8u_C1(
(const Ipp8u*)guard - 256,
(const Ipp8u*)guard - 256,
256,
(Ipp8u*)dest+8
);
ippiSampleUpRowH2V2_Triangle_JPEG_8u_C1 fails due to access violation, trying to read 16 bytes from (const Ipp8u*)guard-13, exactly as described by Paul.
Tested against IPP version 5.1, Visual Studio 2005, any build configuration (release/debug, win32/win64). One system is Windows 7 the other is Windows XP, both running on Intel Core2 Quad CPU Q9550 @ 2.83GHz.
Reproducible: always.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
http://software.intel.com/en-us/articles/intel-ipp-library-61-fixes-list/
If at least 1 byte of src belongs to 16-byte aligned paragraph - all bytes from this pargraph can be read. Corresponding fix applied in IPP 6.1.
I just try IPP 7.0.5 with yakov.galka's test case on windows 7 64bit. the problem should be fixed in the version.
Thanks
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Good to know that latest version works fine..
Thanks,
Naveen Gv
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Im testing IPP Jpeg lib and it looks like it fails on some images, when JpegLibs input buffer size differs from default 4096 value. I can reproduce the problem with djpeg application from your samples, just changing the follwing value:
[cpp]#define INPUT_BUF_SIZE 100096 [/cpp]
I get access violation in jdhuff.c:1001 when memmove tries to use overflowed value as data size.
[cpp]/* Decode a single block's worth of coefficients */ if(state.ipp_need_update == 1) { // fails here memmove(state.ipp_buffer, state.ipp_buffer + state.ipp_bytes_decoded, state.ipp_bytes_in_buffer - state.ipp_bytes_decoded); state.ipp_bytes_in_buffer = state.ipp_bytes_in_buffer - state.ipp_bytes_decoded - ipp_bytes_left - state.sync_shift; //...[/cpp]
Most of my test jpegs works fine, so Im attaching failed jpeg.
My configuration:
Windows 7 x64
IPP version: 7.0.205, win32 binaries
w_ipp-samples_p_7.0.6.060
Thanks,
Eugene
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page