OpenEXR developer list

Nikolaj Thygesen | 1 Mar 23:46

Picon

Re: OpenEXR from shared libs.

    I must shamefully admit that the pure virtual msg of my previous 
mail was caused by some debugging code of mine :o/ Though after fixing 
this, my code still Seg-faults a while after finishing reading the 
image, which, in some cases, I get to see. I don't know what would 
happen if running my EXR code compiled into my main program instead of 
keeping it in an .so as is presently the case.
    I know 1.2.2 is a tad old, so I tried to build 1.4.0a myself, and 
run "make check" which yielded the following partial output when 
checking the RGBA interface:

file with missing and broken scan lines
writing
reading one scan line at a time, comparing
reading multiple scan lines at a time, comparing

number of threads: 1
channels RGBA, line order 0, compression 0
channels RGB, line order 0, compression 0
channels A, line order 0, compression 0
channels RB, line order 0, compression 0
channels RGBA, line order 0, compression 1
channels RGB, line order 0, compression 1
channels A, line order 0, compression 1
channels RB, line order 0, compression 1
channels RGBA, line order 0, compression 2
channels RGB, line order 0, compression 2
channels A, line order 0, compression 2
channels RB, line order 0, compression 2
channels RGBA, line order 0, compression 3
channels RGB, line order 0, compression 3

(Continue reading)

Jim Hourihan | 2 Mar 00:50

Re: OpenEXR from shared libs.


I have had problems when building newer versions of EXR: sometimes  
the build picks up my installed (older headers).  This is certainly  
caused by something in my environment, but you might want to nuke the  
existing install before building the newer version like I do. Perhaps  
you're having a similar problem.

	-Jim

On Mar 1, 2007, at 2:46 PM, Nikolaj Thygesen wrote:

>    I must shamefully admit that the pure virtual msg of my previous  
> mail was caused by some debugging code of mine :o/ Though after  
> fixing this, my code still Seg-faults a while after finishing  
> reading the image, which, in some cases, I get to see. I don't know  
> what would happen if running my EXR code compiled into my main  
> program instead of keeping it in an .so as is presently the case.
>    I know 1.2.2 is a tad old, so I tried to build 1.4.0a myself,  
> and run "make check" which yielded the following partial output  
> when checking the RGBA interface:
>
> file with missing and broken scan lines
> writing
> reading one scan line at a time, comparing
> reading multiple scan lines at a time, comparing
>
> number of threads: 1
> channels RGBA, line order 0, compression 0
> channels RGB, line order 0, compression 0
> channels A, line order 0, compression 0

(Continue reading)

Florian Kainz | 2 Mar 01:24

Re: OpenEXR from shared libs.

I have never seen this particular failure.
Is anyone else using openexr-1.4.0 on FreeBSD?
If you are, do the confidence tests work for you?

Nikolaj Thygesen wrote:
>    I must shamefully admit that the pure virtual msg of my previous mail 
> was caused by some debugging code of mine :o/ Though after fixing this, 
> my code still Seg-faults a while after finishing reading the image, 
> which, in some cases, I get to see. I don't know what would happen if 
> running my EXR code compiled into my main program instead of keeping it 
> in an .so as is presently the case.
>    I know 1.2.2 is a tad old, so I tried to build 1.4.0a myself, and run 
> "make check" which yielded the following partial output when checking 
> the RGBA interface:
> 
> file with missing and broken scan lines
> writing
> reading one scan line at a time, comparing
> reading multiple scan lines at a time, comparing
> 
> number of threads: 1
> channels RGBA, line order 0, compression 0
> channels RGB, line order 0, compression 0
> channels A, line order 0, compression 0
> channels RB, line order 0, compression 0
> channels RGBA, line order 0, compression 1
> channels RGB, line order 0, compression 1
> channels A, line order 0, compression 1
> channels RB, line order 0, compression 1
> channels RGBA, line order 0, compression 2

(Continue reading)

darby johnston | 2 Mar 20:06

Picon

Re: OpenEXR from shared libs.

--- Florian Kainz <kainz <at> ilm.com> wrote:

> I have never seen this particular failure.
> Is anyone else using openexr-1.4.0 on FreeBSD?
> If you are, do the confidence tests work for you?

Just tried on FreeBSD 6.2 x86 and got a seg fault at
the same place. Looks like it has something to with
threads?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x80e1400 (LWP 100079)]
Imf::(anonymous namespace)::hufBuildEncTable
(frq=0xbf85bd70, im=0xbf85bd68,
    iM=0xbf85bd6c) at ImfHuf.cpp:276
276     {
(gdb) where
#0  Imf::(anonymous namespace)::hufBuildEncTable
(frq=0xbf85bd70, im=0xbf85bd68, iM=0xbf85bd6c) at
ImfHuf.cpp:276
#1  0x281034a3 in Imf::hufCompress (raw=0x812d000,
nRaw=30336, compressed=0x813d77f "") at
ImfAutoArray.h:81
#2  0x28105e4d in Imf::PizCompressor::compress
(this=0x80e49c0, inPtr=0x819cd00 "", inSize=60672,
range=Error accessing memory address 0x60: Bad
address.
) at ImfPizCompressor.cpp:478
#3  0x2810610d in Imf::PizCompressor::compress
(this=0x80e49c0, inPtr=0x818e000 "", inSize=60672,

(Continue reading)

Florian Kainz | 2 Mar 20:42

Re: OpenEXR from shared libs.

Is it possible that you are running into the same problem
as Jim Hourihan, where the build conflicts with an older
version that's already installed?

Without access to FreeBSD, I don't know how to debug this issue.

darby johnston wrote:
> --- Florian Kainz <kainz <at> ilm.com> wrote:
> 
>>I have never seen this particular failure.
>>Is anyone else using openexr-1.4.0 on FreeBSD?
>>If you are, do the confidence tests work for you?
> 
> Just tried on FreeBSD 6.2 x86 and got a seg fault at
> the same place. Looks like it has something to with
> threads?
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x80e1400 (LWP 100079)]
> Imf::(anonymous namespace)::hufBuildEncTable
> (frq=0xbf85bd70, im=0xbf85bd68,
>     iM=0xbf85bd6c) at ImfHuf.cpp:276
> 276     {
> (gdb) where
> #0  Imf::(anonymous namespace)::hufBuildEncTable
> (frq=0xbf85bd70, im=0xbf85bd68, iM=0xbf85bd6c) at
> ImfHuf.cpp:276
> #1  0x281034a3 in Imf::hufCompress (raw=0x812d000,
> nRaw=30336, compressed=0x813d77f "") at
> ImfAutoArray.h:81

(Continue reading)

darby johnston | 3 Mar 00:05

Picon

Re: OpenEXR from shared libs.

--- Florian Kainz <kainz <at> ilm.com> wrote:

> Is it possible that you are running into the same
> problem
> as Jim Hourihan, where the build conflicts with an
> older
> version that's already installed?

I double-checked with ldd and it looked ok.

> Without access to FreeBSD, I don't know how to debug
> this issue.

Disabling threading seems to be a workaround.

Also, after looking at the stack trace I tried running
the tests with threading enabled, but without using
PIZ compression, and the tests passed.

Jim Hourihan | 3 Mar 00:47

Re: OpenEXR from shared libs.

On Mar 2, 2007, at 3:05 PM, darby johnston wrote:

> --- Florian Kainz <kainz <at> ilm.com> wrote:
>
>> Is it possible that you are running into the same
>> problem
>> as Jim Hourihan, where the build conflicts with an
>> older
>> version that's already installed?
>
> I double-checked with ldd and it looked ok.

That won't tell you. The problem I was describing occurs when  
building the new version of EXR in the presence of an existing  
install -- if the new build picks up "mildly" compatible .h files you  
can get a skewed build of EXR (this is only possible in certain  
unlikely circumstances, yet it has happened to me).

The only way to be sure is to remove the installed EXR include files.

	-Jim

Florian Kainz | 3 Mar 01:13

Re: OpenEXR from shared libs.

Darby, Nikolaj,

I wonder if the problem has something to do with the size
of the stack when threads are enabled.  Could you please
try this:

In file IlmImf/ImfAutoArray.h, replace the line that reads

     #if defined (HAVE_DARWIN) || defined (_WIN32) || defined (_WIN64)

with

     #if 1

Then rebuild from scratch and re-run the convidence tests.

Florian

darby johnston wrote:
> --- Florian Kainz <kainz <at> ilm.com> wrote:
> 
>>Is it possible that you are running into the same
>>problem
>>as Jim Hourihan, where the build conflicts with an
>>older
>>version that's already installed?
> 
> I double-checked with ldd and it looked ok.
> 
>>Without access to FreeBSD, I don't know how to debug

(Continue reading)

darby johnston | 3 Mar 01:18

Picon

Re: OpenEXR from shared libs.

--- Jim Hourihan <jimh <at> tweakfilms.com> wrote:

> On Mar 2, 2007, at 3:05 PM, darby johnston wrote:
> 
> > I double-checked with ldd and it looked ok.
> 
> That won't tell you.

I checked and there's no other versions of exr
installed.

Darby

darby johnston | 3 Mar 02:20

Picon

Re: OpenEXR from shared libs.


--- Florian Kainz <kainz <at> ilm.com> wrote:

> I wonder if the problem has something to do with the
> size
> of the stack when threads are enabled.

Nice one; looks like that fixed it. 

How about:

#if defined (HAVE_DARWIN) || defined (_WIN32) \
  || defined (_WIN64) || defined(__FreeBSD__)

Or would a test in the configure script be better?

Thanks, Darby

Group

gmane.comp.video.openexr.devel.

Project Web Page

OpenEXR developer list

Search Archive

Page

1 | 2 | 3 | 4 | 5

Articles in period: 47

March 2007

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

Unpacking the multiView attribute? (3 Feb 20:12)
Configure Glitch on MacOS-X Kernel Version 10.7.0 (25 Jan 16:08)
binary exrviewer for Windows? (15 Nov 23:32)
git repository (21 Sep 23:31)
EXR Image File MIME Type? (21 Sep 16:51)
(no subject) (13 Sep 00:42)
OpenCV and OpenEXR (8 Sep 17:01)
openexr_viewers-1.0.1: library not found for -lIlmImfCtl (7 Sep 23:14)
OpenEXR 1.7.0 build on OS X Lion (25 Aug 10:43)
OpenEXR 1.7.0 build on OS X Lion (20 Aug 07:36)
Open Source VFX "Beer of a Feather" at SIGGRAPH 2011 (5 Aug 16:49)
DisplayWindow example images - -1, -1 display window origin? (1 Aug 16:18)
openexr 2.0 (20 Jul 21:07)
Vector-of-float to vector-of-half conversion? (19 Jul 20:19)
Small compile warnings (20 Jun 23:01)
Source Control (20 May 18:47)
Source Control (19 May 22:24)
Small compile error (13 May 20:02)
Linker errors (27 Apr 20:42)
Per-pixel Object Identifiers? (15 Apr 00:13)
All-Static Build on Windows? (8 Apr 22:27)

Archives

6	February 2012
2	January 2012
2	November 2011
8	September 2011
12	August 2011
5	July 2011
2	June 2011
18	May 2011
15	April 2011
15	January 2011
9	November 2010
9	October 2010
6	September 2010
34	August 2010
4	June 2010
6	May 2010
31	March 2010
5	February 2010
12	December 2009
2	November 2009
2	October 2009
11	September 2009
11	July 2009
18	June 2009
4	May 2009
23	March 2009
5	February 2009
7	January 2009
4	December 2008
6	November 2008
18	October 2008
10	September 2008
11	August 2008
4	July 2008
19	June 2008
9	May 2008
8	April 2008
11	March 2008
12	February 2008
11	January 2008
30	December 2007
13	November 2007
9	October 2007
3	September 2007
26	August 2007
2	July 2007
11	June 2007
33	May 2007
11	April 2007
47	March 2007
9	February 2007
35	January 2007
49	December 2006
22	October 2006
23	September 2006
19	August 2006
17	July 2006
27	June 2006
11	May 2006
15	April 2006
29	March 2006
23	February 2006
55	January 2006
22	December 2005
17	November 2005
17	October 2005
10	September 2005
15	August 2005
48	July 2005
18	June 2005
14	May 2005
20	April 2005
91	March 2005
51	February 2005
27	January 2005
13	December 2004
54	November 2004
45	October 2004
57	September 2004
74	August 2004
17	July 2004
52	June 2004
58	May 2004
21	April 2004
35	March 2004
34	February 2004
112	January 2004
39	December 2003
31	November 2003
45	October 2003
9	September 2003
25	August 2003
25	July 2003
18	June 2003
16	May 2003
57	April 2003
116	March 2003
16	February 2003
58	January 2003
2	March 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template