Running cbc release 2.2.2 on miplib2003 problem a1c1s2.mps crashes with bad_alloc. Unfortunately, the problem occurs at various places when trying to reproduce it.
We've reproduced it several time on a windows XP computer with the command line version of cbc 2.2.2, compiled with MS Visual studio 2008, see attached file for details. We can also reproduce the problem with some older cbc 2.1.0 executable in WInXP. That code was compiled with MS Visuals Studio 2005 and uses STLPort, rather than the STL from Microsoft.
When using the pthread patch described in cbc-trac item Trac#45 the problem also occurs in a parallel environment.
So far, however, we have not been able to reproduce the problem on (a slower) linux system with gcc 4.1.2. I.e. we started several runs with varying parameters, but none crashed within the first 2 hours, whereas on WinXP most runs crashes after about 10-60minutes.
It should be noted that all computers used for tests have at least 2GB of main memory and that we never used more than 500 MB of memory when the process crashed (at least that's the amount given by the task manager). The malloc-command that causes the bad alloc requests between 100k - 600k, so nothing special.
We've attached a file with more details and some call stacks. maybe this is of help.
=====
from forrest:
This could be windows malloc problem as other people have found
Attachment: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-75.zip
Running cbc release 2.2.2 on miplib2003 problem a1c1s2.mps crashes with bad_alloc. Unfortunately, the problem occurs at various places when trying to reproduce it.
We've reproduced it several time on a windows XP computer with the command line version of cbc 2.2.2, compiled with MS Visual studio 2008, see attached file for details. We can also reproduce the problem with some older cbc 2.1.0 executable in WInXP. That code was compiled with MS Visuals Studio 2005 and uses STLPort, rather than the STL from Microsoft.
When using the pthread patch described in cbc-trac item Trac#45 the problem also occurs in a parallel environment.
So far, however, we have not been able to reproduce the problem on (a slower) linux system with gcc 4.1.2. I.e. we started several runs with varying parameters, but none crashed within the first 2 hours, whereas on WinXP most runs crashes after about 10-60minutes.
It should be noted that all computers used for tests have at least 2GB of main memory and that we never used more than 500 MB of memory when the process crashed (at least that's the amount given by the task manager). The malloc-command that causes the bad alloc requests between 100k - 600k, so nothing special.
We've attached a file with more details and some call stacks. maybe this is of help.
=====
from forrest: This could be windows malloc problem as other people have found