🚀 go-pugleaf

Bug report
__________

affected : XPRISM2

I remail this message with some more explanations because nobody condescend
to give me a sign after my first sent. I'm amazed because the bug is quite
important on the platform I use (see more details hereafter).

NB: I have already sent the message to khoros-bug but without any success.
    Please may somebody give to me the way to follow if this is a wrong one!


Here follows what I have already sent :

} I've recently installed Khoros 1.5 on a Cray Y-MP2E/116. After some lucky
} tentatives, I was trying to use the xprism2 module with the following data
} set as input but the program crashed.
}
}     0.368337    0.710229
}     0.584199    0.458490
}     0.777301    0.185787
}     0.940948    0.150590
}     1.105010    0.080168
}     1.304155    0.052297
}     1.514984    0.031423
}     1.669611    0.026742
}     1.832500    0.021212
}     2.032305    0.016379
}
} As the problem didn't subsist with data input ranging from 0.0 to 4.0
} (that means something easier to calculate the tics), I had a look at the
} routines called by xprism2.
} I've found the routine :
}
}       $KHOROS_HOME/src/xvroutines/Lib/xvplot/axes2.c
}
} And more specifically the module :
}
}       xtics_xp2
}
} Here follows an extract of this module where I've put a 'printf' instruction
} to get the value of some used variables.
}
}       /* malloc memory for the coords and the labels
}          * add the +1 to the malloc in case we need
}          * room for the end point, if we dont need room
}          * then we malloced and extra point.
}          */
}
}       tic_lines =  (Coord *)malloc((unsigned)
}                     (sizeof(Coord) * 2 * ( num_new_minor_tics +
}                        num_minor_tics + (num_tics + 1))));
} printf("%d %d %d\n", num_new_minor_tics , num_minor_tics , num_tics + 1);
}
} The returned value was the following :
}
}       num_new_minor_tics = -1
}
} What is of course wrong! This value MUST be > or = to zero or the 'malloc'
} will be incorrect. In this case, too small.
}


Here is the new part :

I've received the following answer from a Khoros user :

]     I just ran XPRISM2 on this file without a hitch.
] Platform == SGI INDIGO running IRIX 4.0.5.
]
]                                        Good Luck With Your Bug,
]
]                                                                Joe

What he said is perfectly true ... for his platform.
I mean, the bug is real but appears only on some platforms, depending on how
works the 'malloc' function. On the Cray Y-MP2E/116, if the reserved memory
is not enough, it irremediably crash.
Therefore, I CAN'T USE XPRISM2 with the data I've to treat.

                        HELP! - HELP! - HELP!

Any eager help or comments will be greatly appreciated.
Thanks in advance.

Muriel.


--------------------------------------------------------------------------
 Muriel TOURNAY                                  ULB/VUB Free Universities
 mail  : mtournay@ulb.ac.be                          SUPERCOMPUTING CENTER
         mtournay@bbrbfu60.bitnet
 phone : (00-32) 02/ 650.37.30
--------------------------------------------------------------------------