Re: [DuMuX] memory corruption in brookscorey.hh?
Hi Edscott, you are right, you have to recompile the complete Dune stack with Clang and the flags for the desired saninitzer. When you use a different build directory, it is easy to switch back to your GCC-built stack. Hope this helps, Christoph Am 22.08.2018 um 18:23 schrieb Edscott Wilson: > Hi, Christoph, > > clang sounds good. I'll give it a try, But will I have to recompile dune > with clang or will it be compatible with gcc generated .a libraries? > > Best Regards, > > Edscott -- Unfortunately, plots are notoriously hard to get right. Partly, the default settings of programs like gnuplot or Excel are to blame for this since these programs make it very convenient to create bad plots. -- Till Tantau, "The TikZ and PGF Packages" ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] memory corruption in brookscorey.hh?
Hi, Christoph, clang sounds good. I'll give it a try, But will I have to recompile dune with clang or will it be compatible with gcc generated .a libraries? Best Regards, Edscott El mar., 21 de ago. de 2018 a la(s) 17:10, Christoph Grüninger ( f...@grueninger.de) escribió: > Hi Edscott, > give AddressSanitizer a try, it is a great tool to find such thing you > describe. Further MemorySanitizer and Undefined Behavior Sanitizer might > turn out to be helpful, too. My best experience with these tools were > when I used the latest Clang compiler. Some of them work with recent > versions of GCC very well, too. > Valgrind might be worth a try. But it has more false positives and the > output is more difficult to understand. > > Kind regards, > Christoph > > Am 21.08.2018 um 18:10 schrieb Edscott Wilson: > > OK. > > I'll dig into the matter a bit further to see if I can solve where the > > problem arises. It might be an incorrect cast somewhere that screws up > > memory locations. > > > > Best regards, > > > > Edscott > > > > > > 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd > > > <mailto:bernd.flemi...@iws.uni-stuttgart.de>>: > > > > Hi Edscott, > > > > can you please open an issue at > > https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues > > <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues> ? > > Due to holiday season, it might take us some time to look at this. > > By opening an issue, it won't be forgotten. > > > > Kind regards > > Bernd > > > > Von: Edscott Wilson > > Gesendet: Donnerstag, 16. August, 23:47 > > Betreff: [DuMuX] memory corruption in brookscorey.hh? > > An: DuMuX User Forum > > > > > > This is weird and should not be happening. I explain. > > > > While debugging a generalized Dirichlet type problem, I am > > encountering a problem with the BrooksCorey material law > > (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). > > > > Here is the code from brookscorey.hh: > > > > 181 using std::min; > > 182 using std::max; > > 183 > > 184 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defined for 0.0 <= sw <= 1.0 > > 185 > > 186 return pow(swe, 2.0/params.lambda() + 3); > > 187 } > > > > Inserting a break before the min(max()) call, I examine the value of > > swe: > > > > Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey > Dumux::RegularizedBrooksCoreyParams >::krw (params=..., > > swe=6.9319619419652626e-17) at > > > > /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 > > 184 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defined for 0.0 <= sw <= 1.0 > > (gdb) print swe > > $11 = 6.9319619419652626e-17 > > > > > > Then I step over the min(max() call and re-examine swe and get a > > corrupted value: > > > > (gdb) next > > 186 return pow(swe, 2.0/params.lambda() + 3); > > (gdb) print swe > > $12 = -3.9159195083267944e+240 > > > > Stepping into the min(max()) function I see that the value which > > should be "1.0" arrives corrupted: > > > > (gdb) > > std::min (__a=@0x7fffae00: 6.9319619419652626e-17, > > __b=@0x7fffae10: -3.9159195083267944e+240) > > at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 > > 200 if (__b < __a) > > (gdb) print __b > > $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 > > > > > > Looks like the "1.0" is being placed on the stack and being > > optimized away after the max() part completes. > > > > Doing some changes to the code and doing the simple eff2abs law > > conversion within the regularizedbrooksCorey class template, the > > problem disappears, as the following gdb output shows: > > > > Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV > Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., > > swe=6.9319619419652626e-17, iS=4.22627533) at > > /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 > > 91 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defin
Re: [DuMuX] memory corruption in brookscorey.hh?
Hi Timo, Problem occurs exactly the same way with or without -O0. In order to test whether problem only occurs with gdb, I add line 185 and run. brookscorey.hh: 184swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 185std::cerr<<"swe returns with: "< Dear Edscott, > > what was your actual problem you are trying to solve? Is this a problem > with Dumux? The code you are showing looks perfectly fine to me. > > Or was this just occurring during debugging? Your comments sound like you > are debugging optimized code. If yes, is there any problem if the code is > compiled with -O0? Not all symbols are always defined if there are > optimized away so it might look like this. > > Timo > > > > Viele Grüße, > Timo > Am 21.08.2018 um 20:40 schrieb Edscott Wilson < > edscott.wilson.gar...@gmail.com>: > > OK. > I'll dig into the matter a bit further to see if I can solve where the > problem arises. It might be an incorrect cast somewhere that screws up > memory locations. > > Best regards, > > Edscott > > > 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd < > bernd.flemi...@iws.uni-stuttgart.de>: > >> Hi Edscott, >> >> can you please open an issue at >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues ? Due >> to holiday season, it might take us some time to look at this. By opening >> an issue, it won't be forgotten. >> >> Kind regards >> Bernd >> >> Von: Edscott Wilson >> Gesendet: Donnerstag, 16. August, 23:47 >> Betreff: [DuMuX] memory corruption in brookscorey.hh? >> An: DuMuX User Forum >> >> >> This is weird and should not be happening. I explain. >> >> While debugging a generalized Dirichlet type problem, I am encountering a >> problem with the BrooksCorey material law >> (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). >> >> Here is the code from brookscorey.hh: >> >> 181 using std::min; >> 182 using std::max; >> 183 >> 184 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> 185 >> 186 return pow(swe, 2.0/params.lambda() + 3); >> 187 } >> >> Inserting a break before the min(max()) call, I examine the value of swe: >> >> Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey> Dumux::RegularizedBrooksCoreyParams >::krw (params=..., >> swe=6.9319619419652626e-17) at >> /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 >> 184 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> (gdb) print swe >> $11 = 6.9319619419652626e-17 >> >> >> Then I step over the min(max() call and re-examine swe and get a >> corrupted value: >> >> (gdb) next >> 186 return pow(swe, 2.0/params.lambda() + 3); >> (gdb) print swe >> $12 = -3.9159195083267944e+240 >> >> Stepping into the min(max()) function I see that the value which should >> be "1.0" arrives corrupted: >> >> (gdb) >> std::min (__a=@0x7fffae00: 6.9319619419652626e-17, >> __b=@0x7fffae10: -3.9159195083267944e+240) >> at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 >> 200 if (__b < __a) >> (gdb) print __b >> $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 >> >> >> Looks like the "1.0" is being placed on the stack and being optimized >> away after the max() part completes. >> >> Doing some changes to the code and doing the simple eff2abs law >> conversion within the regularizedbrooksCorey class template, the problem >> disappears, as the following gdb output shows: >> >> Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV> Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., >> swe=6.9319619419652626e-17, iS=4.22627533) at >> /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 >> 91 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> (gdb) step >> std::max (__a=@0x7fffade0: 6.9319619419652626e-17, >> __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 >> 224 if (__a < __b) >> (gdb) next >> 226 return __a; >> (gdb) >> 227 } >> (gdb) >> Dumux::BrooksCoreyV >> >::krw (params=..., swe=6.93
Re: [DuMuX] memory corruption in brookscorey.hh?
Hi Edscott, give AddressSanitizer a try, it is a great tool to find such thing you describe. Further MemorySanitizer and Undefined Behavior Sanitizer might turn out to be helpful, too. My best experience with these tools were when I used the latest Clang compiler. Some of them work with recent versions of GCC very well, too. Valgrind might be worth a try. But it has more false positives and the output is more difficult to understand. Kind regards, Christoph Am 21.08.2018 um 18:10 schrieb Edscott Wilson: > OK. > I'll dig into the matter a bit further to see if I can solve where the > problem arises. It might be an incorrect cast somewhere that screws up > memory locations. > > Best regards, > > Edscott > > > 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd > <mailto:bernd.flemi...@iws.uni-stuttgart.de>>: > > Hi Edscott, > > can you please open an issue at > https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues > <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues> ? > Due to holiday season, it might take us some time to look at this. > By opening an issue, it won't be forgotten. > > Kind regards > Bernd > > Von: Edscott Wilson > Gesendet: Donnerstag, 16. August, 23:47 > Betreff: [DuMuX] memory corruption in brookscorey.hh? > An: DuMuX User Forum > > > This is weird and should not be happening. I explain. > > While debugging a generalized Dirichlet type problem, I am > encountering a problem with the BrooksCorey material law > (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). > > Here is the code from brookscorey.hh: > > 181 using std::min; > 182 using std::max; > 183 > 184 swe = min(max(swe, 0.0), 1.0); // the equation below > is only defined for 0.0 <= sw <= 1.0 > 185 > 186 return pow(swe, 2.0/params.lambda() + 3); > 187 } > > Inserting a break before the min(max()) call, I examine the value of > swe: > > Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey Dumux::RegularizedBrooksCoreyParams >::krw (params=..., > swe=6.9319619419652626e-17) at > > /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 > 184 swe = min(max(swe, 0.0), 1.0); // the equation below > is only defined for 0.0 <= sw <= 1.0 > (gdb) print swe > $11 = 6.9319619419652626e-17 > > > Then I step over the min(max() call and re-examine swe and get a > corrupted value: > > (gdb) next > 186 return pow(swe, 2.0/params.lambda() + 3); > (gdb) print swe > $12 = -3.9159195083267944e+240 > > Stepping into the min(max()) function I see that the value which > should be "1.0" arrives corrupted: > > (gdb) > std::min (__a=@0x7fffae00: 6.9319619419652626e-17, > __b=@0x7fffae10: -3.9159195083267944e+240) > at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 > 200 if (__b < __a) > (gdb) print __b > $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 > > > Looks like the "1.0" is being placed on the stack and being > optimized away after the max() part completes. > > Doing some changes to the code and doing the simple eff2abs law > conversion within the regularizedbrooksCorey class template, the > problem disappears, as the following gdb output shows: > > Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., > swe=6.9319619419652626e-17, iS=4.22627533) at > /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 > 91 swe = min(max(swe, 0.0), 1.0); // the equation below > is only defined for 0.0 <= sw <= 1.0 > (gdb) step > std::max (__a=@0x7fffade0: 6.9319619419652626e-17, > __b=@0x7fffadf8: 0) at > /usr/include/c++/6.3.1/bits/stl_algobase.h:224 > 224 if (__a < __b) > (gdb) next > 226 return __a; > (gdb) > 227 } > (gdb) > Dumux::BrooksCoreyV Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., > swe=6.9319619419652626e-17, iS=4.22627533) > at > /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:92 > 92 return pow(swe, 2.0/params.lambda(iS) + 3); > (gdb) print swe > $18 = 6.9
Re: [DuMuX] memory corruption in brookscorey.hh?
Dear Edscott, what was your actual problem you are trying to solve? Is this a problem with Dumux? The code you are showing looks perfectly fine to me. Or was this just occurring during debugging? Your comments sound like you are debugging optimized code. If yes, is there any problem if the code is compiled with -O0? Not all symbols are always defined if there are optimized away so it might look like this. Timo Viele Grüße, Timo > Am 21.08.2018 um 20:40 schrieb Edscott Wilson > : > > OK. > I'll dig into the matter a bit further to see if I can solve where the > problem arises. It might be an incorrect cast somewhere that screws up memory > locations. > > Best regards, > > Edscott > > > 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd > : >> Hi Edscott, >> >> can you please open an issue at >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues ? Due to >> holiday season, it might take us some time to look at this. By opening an >> issue, it won't be forgotten. >> >> Kind regards >> Bernd >> >> Von: Edscott Wilson >> Gesendet: Donnerstag, 16. August, 23:47 >> Betreff: [DuMuX] memory corruption in brookscorey.hh? >> An: DuMuX User Forum >> >> >> This is weird and should not be happening. I explain. >> >> While debugging a generalized Dirichlet type problem, I am encountering a >> problem with the BrooksCorey material law >> (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). >> >> Here is the code from brookscorey.hh: >> >> 181 using std::min; >> 182 using std::max; >> 183 >> 184 swe = min(max(swe, 0.0), 1.0); // the equation below is only >> defined for 0.0 <= sw <= 1.0 >> 185 >> 186 return pow(swe, 2.0/params.lambda() + 3); >> 187 } >> >> Inserting a break before the min(max()) call, I examine the value of swe: >> >> Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey> Dumux::RegularizedBrooksCoreyParams >::krw (params=..., >> swe=6.9319619419652626e-17) at >> /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 >> 184 swe = min(max(swe, 0.0), 1.0); // the equation below is only >> defined for 0.0 <= sw <= 1.0 >> (gdb) print swe >> $11 = 6.9319619419652626e-17 >> >> >> Then I step over the min(max() call and re-examine swe and get a corrupted >> value: >> >> (gdb) next >> 186 return pow(swe, 2.0/params.lambda() + 3); >> (gdb) print swe >> $12 = -3.9159195083267944e+240 >> >> Stepping into the min(max()) function I see that the value which should be >> "1.0" arrives corrupted: >> >> (gdb) >> std::min (__a=@0x7fffae00: 6.9319619419652626e-17, >> __b=@0x7fffae10: -3.9159195083267944e+240) >> at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 >> 200 if (__b < __a) >> (gdb) print __b >> $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 >> >> >> Looks like the "1.0" is being placed on the stack and being optimized away >> after the max() part completes. >> >> Doing some changes to the code and doing the simple eff2abs law conversion >> within the regularizedbrooksCorey class template, the problem disappears, as >> the following gdb output shows: >> >> Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV> Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., >> swe=6.9319619419652626e-17, iS=4.22627533) at >> /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 >> 91 swe = min(max(swe, 0.0), 1.0); // the equation below is only >> defined for 0.0 <= sw <= 1.0 >> (gdb) step >> std::max (__a=@0x7fffade0: 6.9319619419652626e-17, >> __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 >> 224 if (__a < __b) >> (gdb) next >> 226 return __a; >> (gdb) >> 227 } >> (gdb) >> Dumux::BrooksCoreyV >> >::krw (params=..., swe=6.9319619419652626e-17, iS=4.22627533) >> at /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:92 >> 92 return pow(swe, 2.0/params.lambda(iS) + 3); >> (gdb) print swe >> $18 = 6.9319619419652626e-17 >> >> >> Opinions? >> >> Could there be something amiss in the EffToAbsLaw class template? >> >> Or could i
Re: [DuMuX] memory corruption in brookscorey.hh?
OK. I'll dig into the matter a bit further to see if I can solve where the problem arises. It might be an incorrect cast somewhere that screws up memory locations. Best regards, Edscott 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd < bernd.flemi...@iws.uni-stuttgart.de>: > Hi Edscott, > > can you please open an issue at https://git.iws.uni-stuttgart. > de/dumux-repositories/dumux/issues ? Due to holiday season, it might take > us some time to look at this. By opening an issue, it won't be forgotten. > > Kind regards > Bernd > > Von: Edscott Wilson > Gesendet: Donnerstag, 16. August, 23:47 > Betreff: [DuMuX] memory corruption in brookscorey.hh? > An: DuMuX User Forum > > > This is weird and should not be happening. I explain. > > While debugging a generalized Dirichlet type problem, I am encountering a > problem with the BrooksCorey material law (dumux/material/ > fluidmatrixinteractions/2p/brookscorey.hh). > > Here is the code from brookscorey.hh: > > 181 using std::min; > 182 using std::max; > 183 > 184 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > 185 > 186 return pow(swe, 2.0/params.lambda() + 3); > 187 } > > Inserting a break before the min(max()) call, I examine the value of swe: > > Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey RegularizedBrooksCoreyParams >::krw (params=..., > swe=6.9319619419652626e-17) at /opt/dune/include/dumux/material/ > fluidmatrixinteractions/2p/brookscorey.hh:184 > 184 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > (gdb) print swe > $11 = 6.9319619419652626e-17 > > > Then I step over the min(max() call and re-examine swe and get a corrupted > value: > > (gdb) next > 186 return pow(swe, 2.0/params.lambda() + 3); > (gdb) print swe > $12 = -3.9159195083267944e+240 > > Stepping into the min(max()) function I see that the value which should be > "1.0" arrives corrupted: > > (gdb) > std::min (__a=@0x7fffae00: 6.9319619419652626e-17, > __b=@0x7fffae10: -3.9159195083267944e+240) > at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 > 200 if (__b < __a) > (gdb) print __b > $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 > > > Looks like the "1.0" is being placed on the stack and being optimized away > after the max() part completes. > > Doing some changes to the code and doing the simple eff2abs law conversion > within the regularizedbrooksCorey class template, the problem disappears, > as the following gdb output shows: > > Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., > swe=6.9319619419652626e-17, iS=4.22627533) at > /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 > 91 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > (gdb) step > std::max (__a=@0x7fffade0: 6.9319619419652626e-17, > __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 > 224 if (__a < __b) > (gdb) next > 226 return __a; > (gdb) > 227 } > (gdb) > Dumux::BrooksCoreyV > >::krw (params=..., swe=6.9319619419652626e-17, iS=4.22627533) > at /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:92 > 92 return pow(swe, 2.0/params.lambda(iS) + 3); > (gdb) print swe > $18 = 6.9319619419652626e-17 > > > Opinions? > > Could there be something amiss in the EffToAbsLaw class template? > > Or could it be a gcc bug? (using "gcc (GCC) 6.3.1 20170109" and "GNU gdb > (GDB) 7.12.1"). > > I tried to use gdb within a docker container with "gcc (GCC) 7.3.1 > 20180312" and "GNU gdb (GDB) 8.1" but I get: > > (gdb) run > Starting program: /home/dumux/projects/lswf-chem11-USE_BC-CACO3_CASO4_ > MGCO3-SIMPLIFIED-UMF/build-cmake/src/lswf-chem11 -ParameterFile > ../SW-b.input > warning: Error disabling address space randomization: Operation not > permitted > warning: Could not trace the inferior process. > Error: > warning: ptrace: Operation not permitted > During startup program exited with code 127. > > Has anybody had luck debugging with gdb within a docker container? > > > The full g++ compiler command is as follows: > > /usr/bin/c++ -Wno-deprecated -ggdb -I/home/dumux/problems/lswf-chem11 > -I/home/dumux/include -I/home/dumux -I/opt/dune/include -DUSE_BC > -DCACO3_CASO4_MGCO3 -DSIMPL
Re: [DuMuX] memory corruption in brookscorey.hh?
Hi Edscott, can you please open an issue at https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues ? Due to holiday season, it might take us some time to look at this. By opening an issue, it won't be forgotten. Kind regards Bernd Von: Edscott Wilson Gesendet: Donnerstag, 16. August, 23:47 Betreff: [DuMuX] memory corruption in brookscorey.hh? An: DuMuX User Forum This is weird and should not be happening. I explain. While debugging a generalized Dirichlet type problem, I am encountering a problem with the BrooksCorey material law (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). Here is the code from brookscorey.hh: 181 using std::min; 182 using std::max; 183 184 swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 185 186 return pow(swe, 2.0/params.lambda() + 3); 187 } Inserting a break before the min(max()) call, I examine the value of swe: Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey >::krw (params=..., swe=6.9319619419652626e-17) at /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 184 swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 (gdb) print swe $11 = 6.9319619419652626e-17 Then I step over the min(max() call and re-examine swe and get a corrupted value: (gdb) next 186 return pow(swe, 2.0/params.lambda() + 3); (gdb) print swe $12 = -3.9159195083267944e+240 Stepping into the min(max()) function I see that the value which should be "1.0" arrives corrupted: (gdb) std::min (__a=@0x7fffae00: 6.9319619419652626e-17, __b=@0x7fffae10: -3.9159195083267944e+240) at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 200 if (__b < __a) (gdb) print __b $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 Looks like the "1.0" is being placed on the stack and being optimized away after the max() part completes. Doing some changes to the code and doing the simple eff2abs law conversion within the regularizedbrooksCorey class template, the problem disappears, as the following gdb output shows: Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV >::krw (params=..., swe=6.9319619419652626e-17, iS=4.22627533) at /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 91 swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 (gdb) step std::max (__a=@0x7fffade0: 6.9319619419652626e-17, __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 224 if (__a < __b) (gdb) next 226 return __a; (gdb) 227 } (gdb) Dumux::BrooksCoreyV >::krw (params=..., swe=6.9319619419652626e-17, iS=4.22627533) at /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:92 92 return pow(swe, 2.0/params.lambda(iS) + 3); (gdb) print swe $18 = 6.9319619419652626e-17 Opinions? Could there be something amiss in the EffToAbsLaw class template? Or could it be a gcc bug? (using "gcc (GCC) 6.3.1 20170109" and "GNU gdb (GDB) 7.12.1"). I tried to use gdb within a docker container with "gcc (GCC) 7.3.1 20180312" and "GNU gdb (GDB) 8.1" but I get: (gdb) run Starting program: /home/dumux/projects/lswf-chem11-USE_BC-CACO3_CASO4_MGCO3-SIMPLIFIED-UMF/build-cmake/src/lswf-chem11 -ParameterFile ../SW-b.input warning: Error disabling address space randomization: Operation not permitted warning: Could not trace the inferior process. Error: warning: ptrace: Operation not permitted During startup program exited with code 127. Has anybody had luck debugging with gdb within a docker container? The full g++ compiler command is as follows: /usr/bin/c++ -Wno-deprecated -ggdb -I/home/dumux/problems/lswf-chem11 -I/home/dumux/include -I/home/dumux -I/opt/dune/include -DUSE_BC -DCACO3_CASO4_MGCO3 -DSIMPLIFIED -DUMF -pthread -rdynamic CMakeFiles/lswf-chem11.dir/lswf-chem11.cc.o -o lswf-chem11 -Wl,-rpath,/usr/lib/openmpi /opt/dune/lib64/libdunefem.a /opt/dune/lib64/libdunealugrid.a /opt/dune/lib64/libdunegrid.a /opt/dune/lib64/libugS3.a /opt/dune/lib64/libugS2.a /opt/dune/lib64/libugL.a /opt/dune/lib64/libdunegeometry.a /opt/dune/lib64/libdunecommon.a -lumfpack -lspqr -lldl -lcholmod -lamd -lcamd -lcolamd -lccolamd -lsuitesparseconfig -pthread /usr/lib/openmpi/libmpi.so -lmetis -lm -pthread /usr/lib/openmpi/libmpi.so -lz -lldl -lspqr -lumfpack -lcholmod -lamd -lcamd -lcolamd -lccolamd -lsuitesparseconfig -lsuperlu -lblas -lparmetis -lmetis -lm -pthread /usr/lib/openmpi/libmpi.so -lmetis -lm -lpsurface /opt/dune/lib64/libdunegrid.a /opt/dune/lib64/libugS3.a /opt/dune/lib64/libugS2.a /opt/dune/lib64/libugL.a /opt/dune/lib64/libdunegeometry.a /opt/dune/lib64/libdunecommon.a -lparmetis
[DuMuX] memory corruption in brookscorey.hh?
This is weird and should not be happening. I explain. While debugging a generalized Dirichlet type problem, I am encountering a problem with the BrooksCorey material law (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). Here is the code from brookscorey.hh: 181 using std::min; 182 using std::max; 183 184 swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 185 186 return pow(swe, 2.0/params.lambda() + 3); 187 } Inserting a break before the min(max()) call, I examine the value of swe: Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey >::krw (params=..., swe=6.9319619419652626e-17) at /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 184 swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 (gdb) print swe $11 = 6.9319619419652626e-17 Then I step over the min(max() call and re-examine swe and get a corrupted value: (gdb) next 186 return pow(swe, 2.0/params.lambda() + 3); (gdb) print swe $12 = -3.9159195083267944e+240 Stepping into the min(max()) function I see that the value which should be "1.0" arrives corrupted: (gdb) std::min (__a=@0x7fffae00: 6.9319619419652626e-17, __b=@0x7fffae10: -3.9159195083267944e+240) at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 200 if (__b < __a) (gdb) print __b $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 Looks like the "1.0" is being placed on the stack and being optimized away after the max() part completes. Doing some changes to the code and doing the simple eff2abs law conversion within the regularizedbrooksCorey class template, the problem disappears, as the following gdb output shows: Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV >::krw (params=..., swe=6.9319619419652626e-17, iS=4.22627533) at /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 91 swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 (gdb) step std::max (__a=@0x7fffade0: 6.9319619419652626e-17, __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 224 if (__a < __b) (gdb) next 226 return __a; (gdb) 227 } (gdb) Dumux::BrooksCoreyV >::krw (params=..., swe=6.9319619419652626e-17, iS=4.22627533) at /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:92 92 return pow(swe, 2.0/params.lambda(iS) + 3); (gdb) print swe $18 = 6.9319619419652626e-17 Opinions? Could there be something amiss in the EffToAbsLaw class template? Or could it be a gcc bug? (using "gcc (GCC) 6.3.1 20170109" and "GNU gdb (GDB) 7.12.1"). I tried to use gdb within a docker container with "gcc (GCC) 7.3.1 20180312" and "GNU gdb (GDB) 8.1" but I get: (gdb) run Starting program: /home/dumux/projects/lswf-chem11-USE_BC-CACO3_CASO4_MGCO3-SIMPLIFIED-UMF/build-cmake/src/lswf-chem11 -ParameterFile ../SW-b.input warning: Error disabling address space randomization: Operation not permitted warning: Could not trace the inferior process. Error: warning: ptrace: Operation not permitted During startup program exited with code 127. Has anybody had luck debugging with gdb within a docker container? The full g++ compiler command is as follows: /usr/bin/c++ -Wno-deprecated -ggdb -I/home/dumux/problems/lswf-chem11 -I/home/dumux/include -I/home/dumux -I/opt/dune/include -DUSE_BC -DCACO3_CASO4_MGCO3 -DSIMPLIFIED -DUMF -pthread -rdynamic CMakeFiles/lswf-chem11.dir/lswf-chem11.cc.o -o lswf-chem11 -Wl,-rpath,/usr/lib/openmpi /opt/dune/lib64/libdunefem.a /opt/dune/lib64/libdunealugrid.a /opt/dune/lib64/libdunegrid.a /opt/dune/lib64/libugS3.a /opt/dune/lib64/libugS2.a /opt/dune/lib64/libugL.a /opt/dune/lib64/libdunegeometry.a /opt/dune/lib64/libdunecommon.a -lumfpack -lspqr -lldl -lcholmod -lamd -lcamd -lcolamd -lccolamd -lsuitesparseconfig -pthread /usr/lib/openmpi/libmpi.so -lmetis -lm -pthread /usr/lib/openmpi/libmpi.so -lz -lldl -lspqr -lumfpack -lcholmod -lamd -lcamd -lcolamd -lccolamd -lsuitesparseconfig -lsuperlu -lblas -lparmetis -lmetis -lm -pthread /usr/lib/openmpi/libmpi.so -lmetis -lm -lpsurface /opt/dune/lib64/libdunegrid.a /opt/dune/lib64/libugS3.a /opt/dune/lib64/libugS2.a /opt/dune/lib64/libugL.a /opt/dune/lib64 /libdunegeometry.a /opt/dune/lib64/libdunecommon.a -lparmetis -lmetis -lm -pthread /usr/lib/openmpi/libmpi.so -lmetis -lm -Wl,-Bstatic -lVc -Wl,-Bdynamic -lgmp -lgmpxx -llapack -lblas -pthread /usr/lib/openmpi/libmpi.so /opt/dune/lib64/libdunefem.a /opt/dune/lib64/libdunealugrid.a /opt/dune/lib64/libdunegrid.a /opt/dune/lib64/libugS3.a /opt/dune/lib64/libugS2.a /opt/dune/lib64/libugL.a /opt/dune/lib64/libdunegeometry.a /opt/dune/lib64/libdunecommon.a -pthread -lpsurface -lmetis -lm -lz -Wl,-Bstatic -lVc -Wl,-Bdynamic -lgmp -lgmpxx
