-------- Forwarded Message -------- From: "Sierra Ansuas, Juan Pablo" <[email protected]> To: Heinrich Schuchardt <[email protected]>, [email protected] <bug-glp [email protected]> Cc: Andrew Makhorin <[email protected]>, "Di Cristofaro, Milton Nadir" <MDiCr [email protected]> Subject: Re: [Fwd: Possible bug in GLPK - Error detected in file env/alloc.c at line 72] Date: Thu, 2 Apr 2020 18:14:30 +0000
> Dear Heinrich, > > I have been working on the project that I have been assigned and > applied the changes you suggested with successful results. > > - glp_prob objects are created, used and deleted by the same thread > - GLPK lib compiled with reentrancy support (checking whether to > enable reentrancy support... yes) > > The program is no longer crashing. Thank you. > > I have looked at the multiseed.c example. The main difference between > that example and the project that I am working on is that I build a > glp_prob from scratch, then using glp_copy_prob make as many copies > as processors are available on the machine. Each thread changes a > couple values on the right hand side and runs the simplex again, > without building the glp_prob again or starting the search from > scratch. > > However, the problem that I am now facing is that when several > threads are calling glp_simplex at the same time, some values appear > to be mixed up such as those returned by glp_get_row_dual. Adding a > mutex (OMP CRITICAL) that contains only the glp_simplex call makes > the problem go away and no issues can be seen, the program generates > the expected output data and ends without errors. > > I have looked at the error and output handling contained in the > multiseed.c example. I ended up using glp_open_tee and redirecting > the output of each thread to a separate file. No warnings were > displayed. > > Thank you very much for your help. > > Regards, > > Juan Pablo Sierra > Desarrollo y Mantenimiento de Modelos > DCU – Melilla – Montevideo > Tel. (+598 2) 155 Int. 3777 > > > > > From: Heinrich Schuchardt <[email protected]> > Sent: Thursday, March 26, 2020 6:46 PM > To: [email protected]; Sierra Ansuas, Juan Pablo > Cc: Andrew Makhorin > Subject: Re: [Fwd: Possible bug in GLPK - Error detected in file > env/alloc.c at line 72] > > On 3/25/20 8:23 PM, Andrew Makhorin wrote: > > -------- Forwarded Message -------- > > From: "Sierra Ansuas, Juan Pablo" <[email protected]> > > To: [email protected] <[email protected]> > > Cc: [email protected] <[email protected]>, "Di Cristofaro, Milton Nadir" > <MDiCristo > > [email protected]> > > Subject: Possible bug in GLPK - Error detected in file env/alloc.c > at > > line 72 > > Date: Wed, 25 Mar 2020 18:34:56 +0000 > > > >> Dear GLPK mantainer(s), > >> > >> I am having problems when trying to run the GLPK solver in a > multi- > >> threaded fashion using its C API and OpenMP. While the solver does > >> appear to work, an error comes up when trying to free the memory > with > >> glp_delete_prob: > >> > >> glp_free: memory allocation error > >> Error detected in file env/alloc.c at line 72 > >> > >> I am no GLPK expert but I would be very grateful if you could > check > >> the provided source code and determine whether this is being > caused > >> by a bug or a simple beginner mistake. > >> > >> Running on an eight core processor, 8GiB ram. Stack size limit: > 2GB > >> (ulimit -s 2000000), Stack size limit per thread: 200MB (export > >> OMP_STACKSIZE=200000). Provided source makes little sense but is > >> quite short and reproduces the problem every time. Compile command > is > >> as follows: > >> > >> gcc test_c.c -o test_c -fopenmp -I/home/user/libglpk/glpk- > >> 4.65/include /home/user/libglpk/glpk- > 4.65/src/.libs/libglpk.so.40.3.0 > >> > >> > >> Regards, > >> > >> Juan Pablo Sierra > > Hello Juan, > > Did you compile GLPK with '--enable-reentrant=yes'? > > You are creating all problems in one thread and then call the solver > in > separate threads. This is not supported by GLPK. > > Please, have a look at: > glpk-4.65/examples/threads/multiseed.c > > Here all GLPK library calls needed for each individual model are > called > within the same separate thread. > > Please, have a look at the error and output handling in the example > too. > > Best regards > > Heinrich > La información contenida en este mensaje y en cualquier archivo > adjunto, es confidencial y está dirigido únicamente al destinatario > del mensaje. Si Ud. no es el destinatario correcto por favor > notifique al remitente respondiendo este mensaje y elimine > inmediatamente de su sistema el e-mail y los posibles archivos > adjuntos. Está prohibida cualquier utilización, difusión o copia de > este e-mail por cualquier persona o entidad que no sean las > especificas destinatarias del mensaje. UTE no acepta ninguna > responsabilidad con respecto a cualquier comunicación que haya sido > emitida incumpliendo nuestra Política de Seguridad de la Información, > así como lo previsto en la Ley 18.331 de Protección de Datos > Personales y Ley 18381 de Acceso a la Información Pública
