Backing up a little - Trying to get LAPACK to work... [SOLVED]

[bruce.labitt at autoliv.com]

gnhlug-discuss-bounces at mail.gnhlug.org wrote on 05/27/2010 09:24:03 AM:

> 
> Bruce Labitt writes:
> 
> > The good news is that I have zgesvd_ from the LAPACK library working. 
> > The bad news is I've wasted a lot of time (the list's and mine) 
finding 
> > the error.  Root cause: did not allocate enough memory for the RWORK 
> > array.  For some reason, a small problem worked, whereas the larger 
one 
> > would not.  In hind sight, this all makes sense.
> 
> I was looking at this last night, in fact.  I was sort-of stumbling
> around in this area of the code as well.  Your comment here:
> 
>   int lwork = 2*max(1, 2*mn+MN );     // this is the wrong size...
> 
> ...kindof drew my attention but because the use of the array is split
> across two files it sort-of threw me for a loop.
> 
> This is the source of your stack-smashing.  This is why the debugger
> tools you were using gave you such strange errors.
> 
> Had you allocated this array on the heap, Valgrind would have told you
> about the problem right away.
> 
> 
> I have couple of suggestions:
> 
> 1:  You have two variables in your code:
> 
>         char JOBU, JOBVT;
>         JOBU = 'A';     JOBVT = 'A';
> 
>     It isn't entirely clear to me that these are right.  You
>     might want to consider transmorgifying these to this:
> 
>         char JOBU[] = "A", JOBVT[] = "A";
> 
>     ...and then making other corresponding changes to the code.
> 
>     I say that this is "unclear" to me because it is unclear to
>     me what the underlying Fortran code is doing with these things.
>     All I know is that your code does not produce nul-terminated
>     C strings, which might lead to some weirdness.
> 
> 2:  your build process turns on the optimizer and also
>     includes debugging symbols.  The thing that you need to 
>     understand is that while you are debugging this stuff, you
>     probably don't want the optimizer turned on, because it makes
>     debugging a lot more tricky.
> 
> --kevin
> -- 

First of all, thanks for looking!

The initialization of lwork, and the comment above, is an interesting red 
herring.  I have yet to figure out what the correct setting of wk is. 
However, the routine zgesvd_ will determine the correct value for me if I 
invoke the routine with lwork = -1.  So as long as the length of wk (and 
lwork) is big enough, the initial value of lwork do not matter.  Once the 
TRUE value of lwork is determined, the function zgesvd_ is called again. 
Of course I need to allocate an array that has wk[lwork] values BEFORE 
calling zgesvd_ again.

I really think the stack smashing was due to *NOT ALLOCATING ANY SPACE FOR 
RWORK*.  Sorry about the yelling.  None of the examples online (that I 
found) showed the initialization of RWORK.  Funny, they showed 
initializing everything else though.  Exercise left to the coder perhaps? 
What I find surprising was that the "small" case actually worked, rather 
than the "large" case NOT working.  Another example of: "Just because it 
works for this case doesn't mean you can stop testing it."

On number 2:  Good catch.  Yeah, -O3 and -g are a *dumb* combination.  I 
was in mid flail at that point.  At this point -g will be taken out.  But 
for later (when stuff goes wrong, again) I'll try to remember to use -O0 
-g !

On number 1:  I dunno.  The documentation, which I no longer trust, 
clearly uses that syntax.  Are they right?  Dunno again.  I did experiment 
at one time using "" rather than ''.  My version of gcc didn't care which 
I used.

-Bruce


******************************
Neither the footer nor anything else in this E-mail is intended to or constitutes an <br>electronic signature and/or legally binding agreement in the absence of an <br>express statement or Autoliv policy and/or procedure to the contrary.<br>This E-mail and any attachments hereto are Autoliv property and may contain legally <br>privileged, confidential and/or proprietary information.<br>The recipient of this E-mail is prohibited from distributing, copying, forwarding or in any way <br>disseminating any material contained within this E-mail without prior written <br>permission from the author. If you receive this E-mail in error, please <br>immediately notify the author and delete this E-mail.  Autoliv disclaims all <br>responsibility and liability for the consequences of any person who fails to <br>abide by the terms herein. <br>
******************************