Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ SMAUG
➜ SMAUG coding
➜ Small GDB problem
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Dark_Trunks
Australia (27 posts) Bio
|
| Date
| Wed 03 Jul 2002 05:00 PM (UTC) Amended on Wed 03 Jul 2002 05:04 PM (UTC) by Dark_Trunks
|
| Message
| I've been trying to setup a new skill and thought I finally got everything working when I descover that it crashes in seemingly random locations. So I figure hey why not give GDB a go.
Now I have a new problem: It wont run past line 159 in comm.c
Why is it doing this? There seems to be a breakpoint on that line that I cant disable - everytime I do, it just puts it back again.
I can step past it and get up to about line 272 when it will go back to 159.
Here is the code in and around those lins:
152 int port;
153
154 #ifdef WIN32
155 int mainthread( int argc, char **argv )
156 #else
157 int main( int argc, char **argv )
158 #endif
159 {
- 160 struct timeval now_time;
161 char hostn[128];
162
163 /*
164 * Memory debugging if needed.
165 */
166 #if defined(MALLOC_DEBUG)
167 malloc_debug( 2 );
168 #endif
169
...
259 if (err)
260 {
261 fprintf(stderr, "Error %i on WSAStartup\n", err);
262 exit(1);
263 }
264
265 /* standard termination signals */
266 signal(SIGINT, (void *) bailout);
267 signal(SIGTERM, (void *) bailout);
268 }
269 #endif /* WIN32 */
270
- 271 log_string("Booting Database");
- 272 boot_db( );
Any help here would be greatly appreciated. | | Top |
|
| Posted by
| Dark_Trunks
Australia (27 posts) Bio
|
| Date
| Reply #1 on Thu 04 Jul 2002 02:33 AM (UTC) |
| Message
| | OK, well I fixed that problem with a little intuitive fiddling, but now I have another question: When the SMAUG server crashes (Segmentation Fault) does it usually cause GDB to fill up the memory and hense make everything run extremely slow? Or is that just my slow system? | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #2 on Sun 07 Jul 2002 10:45 PM (UTC) |
| Message
| | Using GDB would take memory, yes, and if you are running it with smallish amounts of memory it might make the system slower. However normally you only use GDB after a crash, so it isn't too big an issue. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Dark_Trunks
Australia (27 posts) Bio
|
| Date
| Reply #3 on Mon 08 Jul 2002 03:14 PM (UTC) |
| Message
| OK well I have 128MB in my system, and I was watching my task manager while it was doing it. The memory usage for gdb got higher than 90MB when I decided to stop it.
So how do I use it after the crash? I've tried to open the stackdump file and it doesnt work. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #4 on Fri 02 Aug 2002 03:38 AM (UTC) |
| Message
| You should be able to specify both the executable and the dump, something like this:
gdb smaug coredump |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
15,568 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top