112855Sgabeblack@google.com/***************************************************************************** 212855Sgabeblack@google.com 312855Sgabeblack@google.com Licensed to Accellera Systems Initiative Inc. (Accellera) under one or 412855Sgabeblack@google.com more contributor license agreements. See the NOTICE file distributed 512855Sgabeblack@google.com with this work for additional information regarding copyright ownership. 612855Sgabeblack@google.com Accellera licenses this file to you under the Apache License, Version 2.0 712855Sgabeblack@google.com (the "License"); you may not use this file except in compliance with the 812855Sgabeblack@google.com License. You may obtain a copy of the License at 912855Sgabeblack@google.com 1012855Sgabeblack@google.com http://www.apache.org/licenses/LICENSE-2.0 1112855Sgabeblack@google.com 1212855Sgabeblack@google.com Unless required by applicable law or agreed to in writing, software 1312855Sgabeblack@google.com distributed under the License is distributed on an "AS IS" BASIS, 1412855Sgabeblack@google.com WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 1512855Sgabeblack@google.com implied. See the License for the specific language governing 1612855Sgabeblack@google.com permissions and limitations under the License. 1712855Sgabeblack@google.com 1812855Sgabeblack@google.com *****************************************************************************/ 1912855Sgabeblack@google.com 2012855Sgabeblack@google.com/***************************************************************************** 2112855Sgabeblack@google.com 2212855Sgabeblack@google.com test01.cpp -- 2312855Sgabeblack@google.com 2412855Sgabeblack@google.com Original Author: Andy Goodrich, Forte Design Systems, 14 March 2006 2512855Sgabeblack@google.com 2612855Sgabeblack@google.com *****************************************************************************/ 2712855Sgabeblack@google.com 2812855Sgabeblack@google.com/***************************************************************************** 2912855Sgabeblack@google.com 3012855Sgabeblack@google.com MODIFICATION LOG - modifiers, enter your name, affiliation, date and 3112855Sgabeblack@google.com changes you are making here. 3212855Sgabeblack@google.com 3312855Sgabeblack@google.com $Log: constructor_throw.cpp,v $ 3412855Sgabeblack@google.com Revision 1.1.1.1 2006/12/15 20:25:56 acg 3512855Sgabeblack@google.com systemc_tests-2.3 3612855Sgabeblack@google.com 3712855Sgabeblack@google.com Revision 1.1 2006/03/15 00:12:08 acg 3812855Sgabeblack@google.com Andy Goodrich: Forte Design Systems 3912855Sgabeblack@google.com First check in. 4012855Sgabeblack@google.com 4112855Sgabeblack@google.com *****************************************************************************/ 4212855Sgabeblack@google.com 4312855Sgabeblack@google.com// This tests a bug when an exception is thrown in 4412855Sgabeblack@google.com// sc_module::sc_module() for a dynamically allocated sc_module 4512855Sgabeblack@google.com// object. We are calling sc_module::end_module() on a module that has 4612855Sgabeblack@google.com// already been deleted. The scenario runs like this: 4712855Sgabeblack@google.com// 4812855Sgabeblack@google.com// a) the sc_module constructor is entered 4912855Sgabeblack@google.com// b) the exception is thrown 5012855Sgabeblack@google.com// c) the exception processor deletes the storage for the sc_module 5112855Sgabeblack@google.com// d) the stack is unrolled causing the sc_module_name instance to be deleted 5212855Sgabeblack@google.com// e) ~sc_module_name() calls end_module() with its pointer to the sc_module 5312855Sgabeblack@google.com// f) because the sc_module has been deleted its storage is corrupted, 5412855Sgabeblack@google.com// either by linking it to a free space chain, or by reuse of some sort 5512855Sgabeblack@google.com// g) the m_simc field is garbage 5612855Sgabeblack@google.com// h) the m_object_manager field is also garbage 5712855Sgabeblack@google.com// i) an exception occurs 5812855Sgabeblack@google.com// 5912855Sgabeblack@google.com// This does not happen for automatic sc_module instances since the 6012855Sgabeblack@google.com// storage for the module is not reclaimed its just part of the stack. 6112855Sgabeblack@google.com// 6212855Sgabeblack@google.com// I am fixing this by having the destructor for sc_module clear the 6312855Sgabeblack@google.com// module pointer in its sc_module_name instance. That cuts things at 6412855Sgabeblack@google.com// step (e) above, since the pointer will be null if the module has 6512855Sgabeblack@google.com// already been deleted. To make sure the module stack is okay, I call 6612855Sgabeblack@google.com// end-module() in ~sc_module in the case where there is an 6712855Sgabeblack@google.com// sc_module_name pointer lying around. 6812855Sgabeblack@google.com 6912855Sgabeblack@google.com#include "systemc.h" 7012855Sgabeblack@google.com 7112855Sgabeblack@google.comSC_MODULE(X) 7212855Sgabeblack@google.com{ 7312855Sgabeblack@google.com SC_CTOR(X) 7412855Sgabeblack@google.com { 7513317Sgabeblack@google.com SC_REPORT_ERROR(SC_ID_SET_TIME_RESOLUTION_,""); 7612855Sgabeblack@google.com } 7712855Sgabeblack@google.com}; 7812855Sgabeblack@google.com 7912855Sgabeblack@google.comint sc_main(int argc, char* argv[]) 8012855Sgabeblack@google.com{ 8112855Sgabeblack@google.com sc_module* x_p = new X("x"); 8212855Sgabeblack@google.com 8312855Sgabeblack@google.com cout << "Program completed" << endl; 8412855Sgabeblack@google.com return 0; 8512855Sgabeblack@google.com} 8612855Sgabeblack@google.com 87