JakubH Posted November 15, 2012 Report Share Posted November 15, 2012 I have one reproducible crash here. I have imported our repository with very long history (almost ten years of development). When I set the date filter in a branch explorer to the full range, the Plastic client crashes. There is an unhandled StackOverflowException in libplastic.dll. I can sent you a minidump (without heap at least), if it helps. Link to comment Share on other sites More sharing options...
manu Posted November 15, 2012 Report Share Posted November 15, 2012 Can you please enable the Plastic GUI log and send to use the last lines? http://www.plasticscm.com/infocenter/technical-articles/kb-enabling-logging-for-plastic-scm-part-i.aspx Link to comment Share on other sites More sharing options...
JakubH Posted November 15, 2012 Author Report Share Posted November 15, 2012 Here it is: 2012-11-15 14:15:13,596 INFO CmProxy - Using profile [PGM server] to connect to [plastic-pgm:8087] 2012-11-15 14:15:13,599 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5) 2012-11-15 14:15:13,599 DEBUG BufferPool - -> Entering with name UncompressionPool (5) 2012-11-15 14:15:13,599 INFO Serialization - Uncompressed 494 bytes in 733 bytes. Time: 0 ms. 2012-11-15 14:15:13,599 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4) 2012-11-15 14:15:13,599 DEBUG BufferPool - <- Releasing with name UncompressionPool (4) 2012-11-15 14:15:13,599 DEBUG ClientSink - | GetRepositoryInfo | proc 0 | 4 | 29126504 2012-11-15 14:15:13,601 INFO CmProxy - Using profile [PGM server] to connect to [plastic-pgm:8087] 2012-11-15 14:15:14,165 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5) 2012-11-15 14:15:14,165 DEBUG BufferPool - -> Entering with name UncompressionPool (5) 2012-11-15 14:15:14,168 INFO Serialization - Uncompressed 200748 bytes in 524771 bytes. Time: 0 ms. 2012-11-15 14:15:14,168 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4) 2012-11-15 14:15:14,202 DEBUG BrEx - BrEx deserialization 31ms 2012-11-15 14:15:14,202 DEBUG BufferPool - <- Releasing with name UncompressionPool (4) 2012-11-15 14:15:14,202 DEBUG ClientSink - | GetReleaseDiagramInfo | proc 593 | 4 | 30664520 2012-11-15 14:15:14,723 INFO CmProxy - Using profile [PGM server] to connect to [plastic-pgm:8087] 2012-11-15 14:15:14,726 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5) 2012-11-15 14:15:14,726 DEBUG BufferPool - -> Entering with name UncompressionPool (5) 2012-11-15 14:15:14,726 INFO Serialization - Uncompressed 494 bytes in 733 bytes. Time: 0 ms. 2012-11-15 14:15:14,726 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4) 2012-11-15 14:15:14,726 DEBUG BufferPool - <- Releasing with name UncompressionPool (4) 2012-11-15 14:15:14,726 DEBUG ClientSink - | GetRepositoryInfo | proc 15 | 11 | 33558448 2012-11-15 14:15:14,726 INFO CmProxy - Using profile [PGM server] to connect to [plastic-pgm:8087] 2012-11-15 14:15:14,763 DEBUG ReplicationSourceControl - Control handle created: True 2012-11-15 14:15:14,781 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5) 2012-11-15 14:15:14,781 DEBUG BufferPool - -> Entering with name UncompressionPool (5) 2012-11-15 14:15:14,781 INFO Serialization - Uncompressed 6131 bytes in 16867 bytes. Time: 0 ms. 2012-11-15 14:15:14,781 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4) 2012-11-15 14:15:14,783 DEBUG BrEx - BrEx deserialization 0ms 2012-11-15 14:15:14,783 DEBUG BufferPool - <- Releasing with name UncompressionPool (4) 2012-11-15 14:15:14,783 DEBUG ClientSink - | GetReleaseDiagramInfo | proc 47 | 11 | 34479592 2012-11-15 14:15:14,801 INFO CmProxy - Using profile [PGM server] to connect to [plastic-pgm:8087] 2012-11-15 14:15:14,851 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5) 2012-11-15 14:15:14,851 DEBUG BufferPool - -> Entering with name UncompressionPool (5) 2012-11-15 14:15:14,851 INFO Serialization - Uncompressed 5378 bytes in 30573 bytes. Time: 0 ms. 2012-11-15 14:15:14,851 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4) 2012-11-15 14:15:14,855 DEBUG BufferPool - <- Releasing with name UncompressionPool (4) 2012-11-15 14:15:14,855 DEBUG ClientSink - | GetMarkerList | proc 62 | 11 | 35948696 2012-11-15 14:15:26,817 INFO CmProxy - Using profile [PGM server] to connect to [plastic-pgm:8087] 2012-11-15 14:15:26,821 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5) 2012-11-15 14:15:26,821 DEBUG BufferPool - -> Entering with name UncompressionPool (5) 2012-11-15 14:15:26,821 INFO Serialization - Uncompressed 494 bytes in 733 bytes. Time: 0 ms. 2012-11-15 14:15:26,821 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4) 2012-11-15 14:15:26,821 DEBUG BufferPool - <- Releasing with name UncompressionPool (4) 2012-11-15 14:15:26,822 DEBUG ClientSink - | GetRepositoryInfo | proc 0 | 13 | 40710560 2012-11-15 14:15:26,822 INFO CmProxy - Using profile [PGM server] to connect to [plastic-pgm:8087] 2012-11-15 14:15:28,711 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5) 2012-11-15 14:15:28,711 DEBUG BufferPool - -> Entering with name UncompressionPool (5) 2012-11-15 14:15:28,721 INFO Serialization - Uncompressed 804187 bytes in 2097635 bytes. Time: 16 ms. 2012-11-15 14:15:28,721 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4) 2012-11-15 14:15:28,783 DEBUG BrEx - BrEx deserialization 62ms 2012-11-15 14:15:28,783 DEBUG BufferPool - <- Releasing with name UncompressionPool (4) 2012-11-15 14:15:28,783 DEBUG ClientSink - | GetReleaseDiagramInfo | proc 1966 | 13 | 52616336 Link to comment Share on other sites More sharing options...
manu Posted November 15, 2012 Report Share Posted November 15, 2012 Not too much information. There must be something in the repository that you imported, a case not supported by plastic in the drawing step. I think there's no much to do if we don't have access to the repository. A fast-export nodata package can help a lot. Link to comment Share on other sites More sharing options...
JakubH Posted November 15, 2012 Author Report Share Posted November 15, 2012 But I can see the whole history piecemeal: 1. 1. 2003 – 1. 1. 2006 ... OK 1. 1. 2005 – 1. 1. 2010 ... OK 1. 1. 2009 – now ... OK 1.1 2003 – now ... stack overflow I will try to fast-export it from Plastic and fast-import it again. If it won't help, I could sent you nodata export from plastic. Link to comment Share on other sites More sharing options...
manu Posted November 15, 2012 Report Share Posted November 15, 2012 Yes, the issue is sure with a relationship of an old item with another newer. Link to comment Share on other sites More sharing options...
JakubH Posted November 15, 2012 Author Report Share Posted November 15, 2012 It doesn't seem so. 1. 1. 2003 – 1. 1. 2010 ... OK 1. 1. 2003 – 1. 1. 2011 ... crash 1. 1. 2004 – 1. 1. 2012 ... OK 1. 1. 2004 – now ... crash 1. 1. 2005 – now ... OK It behaves like if there was a limit for changesets count. The history is pretty simple – one linear trunk with one linear branch, which has started two months ago. Link to comment Share on other sites More sharing options...
manu Posted November 16, 2012 Report Share Posted November 16, 2012 Thanks for all the information. I will try to fast-export it from Plastic and fast-import it again. If it won't help, I could sent you nodata export from plastic. Please do it, let's try to get it fixed. Link to comment Share on other sites More sharing options...
JakubH Posted November 16, 2012 Author Report Share Posted November 16, 2012 Export – import didn't help. I've generated a nodata fast-export file and sent it to your e-mail. Link to comment Share on other sites More sharing options...
manu Posted November 19, 2012 Report Share Posted November 19, 2012 Cool. I'm able to reproduce the issue with a 4.1 release. The brand new 4.2 is working (It has a new layout algorithm) If you really need to get it working you can jump to the 4.2 beta edition. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.