From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2309 invoked by alias); 9 Jun 2009 22:15:13 -0000 Received: (qmail 2010 invoked by uid 48); 9 Jun 2009 22:14:59 -0000 Date: Tue, 09 Jun 2009 22:15:00 -0000 Message-ID: <20090609221459.2009.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/40330] [4.4 Regression] incorrect IO In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jv244 at cam dot ac dot uk" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00594.txt.bz2 ------- Comment #15 from jv244 at cam dot ac dot uk 2009-06-09 22:14 ------- (In reply to comment #14) > Closing as fixed. I'm testing now 4.4 which includes your fix, but I still see CP2K's restarts failing. This looks like a second issue, different from what you've fixed so far. The testcase of comment #5 is working fine, with the update 4.4.1, but CP2K runs still shows a valgrind warning: ==11664== ==11664== Invalid read of size 1 ==11664== at 0x4BE3C4C: formatted_transfer (transfer.c:874) ==11664== by 0x6312C5: __input_section_types_MOD_section_vals_write (input_section_types.F:2040) ==11664== by 0x632964: __input_section_types_MOD_section_vals_write (input_section_types.F:2083) ==11664== by 0xF10D05: __replica_types_MOD_rep_env_create (replica_types.F:278) ==11664== by 0x11996B9: __vibrational_analysis_MOD_vb_anal (vibrational_analysis.F:143) ==11664== by 0x40E83A: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:385) ==11664== by 0x404E93: __cp2k_runs_MOD_run_input (cp2k_runs.F:1095) ==11664== by 0x403EBF: MAIN__ (cp2k.F:272) ==11664== by 0x2CFF029: main (fmain.c:21) ==11664== Address 0x6ada7c6 is 6 bytes inside a block of size 640 free'd ==11664== at 0x4A2196E: free (vg_replace_malloc.c:323) ==11664== by 0x631306: __input_section_types_MOD_section_vals_write (input_section_types.F:2040) ==11664== by 0x632964: __input_section_types_MOD_section_vals_write (input_section_types.F:2083) ==11664== by 0xF10D05: __replica_types_MOD_rep_env_create (replica_types.F:278) ==11664== by 0x11996B9: __vibrational_analysis_MOD_vb_anal (vibrational_analysis.F:143) ==11664== by 0x40E83A: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:385) ==11664== by 0x404E93: __cp2k_runs_MOD_run_input (cp2k_runs.F:1095) ==11664== by 0x403EBF: MAIN__ (cp2k.F:272) ==11664== by 0x2CFF029: main (fmain.c:21) ==11664== ==11664== Invalid read of size 1 ==11664== at 0x4BE3C60: formatted_transfer (transfer.c:878) ==11664== by 0x6312C5: __input_section_types_MOD_section_vals_write (input_section_types.F:2040) ==11664== by 0x632964: __input_section_types_MOD_section_vals_write (input_section_types.F:2083) ==11664== by 0xF10D05: __replica_types_MOD_rep_env_create (replica_types.F:278) ==11664== by 0x11996B9: __vibrational_analysis_MOD_vb_anal (vibrational_analysis.F:143) ==11664== by 0x40E83A: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:385) ==11664== by 0x404E93: __cp2k_runs_MOD_run_input (cp2k_runs.F:1095) ==11664== by 0x403EBF: MAIN__ (cp2k.F:272) ==11664== by 0x2CFF029: main (fmain.c:21) ==11664== Address 0x6ada7c7 is 7 bytes inside a block of size 640 free'd ==11664== at 0x4A2196E: free (vg_replace_malloc.c:323) ==11664== by 0x631306: __input_section_types_MOD_section_vals_write (input_section_types.F:2040) ==11664== by 0x632964: __input_section_types_MOD_section_vals_write (input_section_types.F:2083) ==11664== by 0xF10D05: __replica_types_MOD_rep_env_create (replica_types.F:278) ==11664== by 0x11996B9: __vibrational_analysis_MOD_vb_anal (vibrational_analysis.F:143) ==11664== by 0x40E83A: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:385) ==11664== by 0x404E93: __cp2k_runs_MOD_run_input (cp2k_runs.F:1095) ==11664== by 0x403EBF: MAIN__ (cp2k.F:272) ==11664== by 0x2CFF029: main (fmain.c:21) linking to the 4.3.2 runtime still solves the issue. I hope you can have a look at what might be wrong with these traces above, I don't have a testcase other than CP2K right now, and the code is tricky to reduce at that point. If you happen to have CP2K around, this is the testcase for the trace: cp2k/tests/Fist/regtest-5> valgrind --tool=memcheck ../../../exe/Linux-x86-64-gfortran/cp2k.sdbg wat_freq.inp -- jv244 at cam dot ac dot uk changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |critical Status|RESOLVED |REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330