| Welcome to UCR CS 14 Klefstad. You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free. Join our community! If you're already a member please log in to your account to access all of our features: |
- Pages:
- 1
- 2
| program killed | |
|---|---|
| Tweet Topic Started: Nov 15 2013, 09:33 PM (202 Views) | |
| Deleted User | Nov 15 2013, 09:33 PM Post #1 |
|
Deleted User
|
How is everyone dealing with the program being killed when you run words.txt? |
|
|
| Replies: | |
|---|---|
| Deleted User | Nov 16 2013, 12:06 AM Post #11 |
|
Deleted User
|
I'm getting insert under 3 minutes as well. It's when I'm testing find that it kills at the 10th partition. I really don't want to go to the labs right now... |
|
|
| Deleted User | Nov 16 2013, 12:19 AM Post #12 |
|
Deleted User
|
It seems odd that it makes it past insert and then blows the call at find. Because of how words.txt is organized, we basically have to iterate down the entire tree (now a singly linked list) to insert each new element. How are you able to get down the entire list for inserting without blowing the call but then become unable to iterate down 10% of the list without blowing the call? Is the method for finding for inserting iterative where as it is recursive for actually finding something in the tree? |
|
|
| Deleted User | Nov 16 2013, 12:21 AM Post #13 |
|
Deleted User
|
I know right? I'm really confused too. My insert and find are now iterative but my remove is recursive. Haven't tested the remove yet but I assume that would blow. |
|
|
| Deleted User | Nov 16 2013, 12:32 AM Post #14 |
|
Deleted User
|
I bet I know what's causing it. I bet a lot of people are on the well/bell right now and that the amount of memory it gives your program for the call stack is determined by how many people are connected. Less if more are connected. That's the only thing that would make sense for causing the call stack to blow with just 10% of 45392 (4539). Granted, find is O(N) for words.txt, but even then, 4539 shouldn't be big enough to blow that stack. |
|
|
| Deleted User | Nov 16 2013, 02:27 AM Post #15 |
|
Deleted User
|
Luckily I have a small luxury of being able to go to the labs at this time. I'm done. I find it really weird too. I mean find is just looking through an already established tree. If we're doing it iteratively, then how does the call stack get blown? |
|
|
| Deleted User | Nov 16 2013, 02:34 AM Post #16 |
|
Deleted User
|
I think well/bell just have stability issues sometimes. I've noticed these occur more often the day before assignments for CS classes are due (probably due to the increased traffic). |
|
|
| 1 user reading this topic (1 Guest and 0 Anonymous) | |
| « Previous Topic · Homework 6 · Next Topic » |
- Pages:
- 1
- 2





12:15 PM Jul 11