[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::axp-developer

Title:Alpha Developer Support
Notice:[email protected], 800-332-4786
Moderator:HYDRA::SYSTEM
Created:Mon Jun 06 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3722
Total number of notes:11359

3254.0. "IBR - Point 21407" by KZIN::ASAP () Mon Mar 03 1997 09:22

    Company Name :  IBR - Point 21407
    Contact Name :  Gerd Heupel
    Phone        :  0049 228 979850
    Fax          :  0049 228 9798555
    Email        :  
    Date/Time in :   3-MAR-1997 14:22:43
    Entered by   :  Hartmut Becker
    SPE center   :  REO

    Category     :  vms
    OS Version   :  
    System H/W   :  


    Brief Description of Problem:
    -----------------------------

From:	ESSB::ESSB::MRGATE::"ILO::ESSC::dlennon"  3-MAR-1997 11:23:13.51
To:	RDGENG::ASAP
CC:	
Subj:	ESCALATION: POINT No., Company TO ASAP READING:    

From:	NAME: ESCTECH@ILO          
	TEL: (822-)6704          
	ADDR: ILO                  <dlennon@ESSC@ILO>
To:	ASAP@RDGENG@MRGATE


Hello - 

POINT Log Number	 21407	

Company Name 	IBR
	
Engineers name	Gerd Heupel

Telephone Number 		0049 228 979850

Fax Number		0049 228 9798555

E-mail Address		

Operating System, Version	OpenVMS, V6.2

Platform			Alpha

Problem Statement		

FORTRAN program crashing on some Alpha systems

Detailed fax on the way to DTN 830 4146
T.RTitleUserPersonal
Name		DateLines
3254.1stack is corruptedMUCTEC::BECKERHartmut B., VMS &amp; Languages, MunichWed Mar 05 1997 06:1713
I'm in contact with the partner. Their problem is a corrupted stack. This is
reproducable but the culprit can't be found. Via phone I gave some debugging
hints. Up to now we only know that "something" asynchroneously writes to the
stack and overwrites two longwords. The partner says he doesn't do anything
with asts or threads. But he uses motif and immediately after the corruption is
observed there are 4 outstanding asts.

At the moment the partner evaluates if the problem is still there with V7.1.
They can upgrade and they know of a customer running 7.1 who didn't report the
problem.

Hartmut
3254.2problem not solved but closedMUCTEC::BECKERHartmut B., VMS &amp; Languages, MunichTue Mar 11 1997 05:139
The problem also shows up on V7.1. He also assumes that the problem is in
the GKS library they use between X and their application. It looks like
someone has to go onsite and help them debugging. It also looks like it
isn't our code which corrupts the stack.

It looks like we can't handle this within ASAP, I'm still in contact with
the partner but I close the call.

Hartmut
3254.3solvedMUCTEC::BECKERHartmut B., VMS &amp; Languages, MunichMon May 05 1997 05:484
It turned out they used an automatic variable from another c function as iosb to
a QIO with AST. This was found by a local support engineer who went onsite.

Hartmut