Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
I'm studying SystemVerilog event data types. But I can't understanda
the simulation results.
How does event works in SystemVerilog?
UPDATE
1 module events();
2 // Declare a new event called ack
3 event ack;
4 // Declare done as alias to ack
5 event done = ack;
6 // Event variable with no synchronization object
7 event empty = null;
9 initial begin
10 #1 -> ack;
11 #1 -> empty;
12 #1 -> done;
13 #1 $finish;
14 end
15
16 always # (ack)
17 begin
18 $display("ack event emitted");
19 end
20
21 always # (done)
22 begin
23 $display("done event emitted");
24 end
25
26 /*
27 always # (empty)
28 begin
29 $display("empty event emitted");
30 end
31 */
32
33 endmodule
How does it show as following?
ack event emitted
done event emitted
ack event emitted <== I don't understand here Why does it happens?
done event emitted
I think that it should be like this.
ack event emitted
done event emitted
done event emitted
I think you may be confused about why the events are printed multiple times? Have a look at line5:
event done = ack;
Now ack and done are synonymous with each other, whenever one event is triggered the other is as well, since each is triggered once you get 4 printouts.
Related
I create an integer to count the number of assemblies (e.g. countAssembler)
On exit from FA1 (countAssembler++;)
Then I have an event triggered by a condition such that when the count of assemblies reaches 10 ((countAssembler==10)), it suspends the FA1 for two hours using suspend function.
But how do I implement the suspend function? Do you have any ideas?
note that the suspend function doesn't suspend the assembler, but an item that is currently being processed in the assembler...
have a variable countAssembler count the number of items produced... then
on exit you write countAssembler++;
on enter delay you write the following:
if(countAssembler==10){
self.suspend(agent);
create_MyDynamicEvent(2, HOUR,agent);
}
on the dynamic event you write:
assembler.resume(agent);
Don't forget to add the parameter needed in the dynamic event:
Note that the suspend will start when part 11 starts being assembled, which means that the machine will be suspended for 2 hours + the time between the 10th assembly end and then 11th assembly start... you can fix that easily but im not including it in my answer
I have run into a behavior of Scala Observables that has surprised me. Consider my example below:
object ObservablesDemo extends App {
val oFast = Observable.interval(3.seconds).map(n => s"[FAST] ${n*3}")
val oSlow = Observable.interval(7.seconds).map(n => s"[SLOW] ${n*7}")
val oBoth = (oFast merge oSlow).take(8)
oBoth.subscribe(println(_))
oBoth.toBlocking.toIterable.last
}
The code demonstrates emitting elements from two observables. One of them emits its elements in a "slow" way (every 7 seconds), the other in a "fast" way (every 3 seconds). For the sake of the question assume we want to define those observables with the use of the map function and map the numbers from the interval appropriately as seen above (as opposed to another possible approach which would be emitting items at the same rate from both observables and then filtering out as needed).
The output of the code seems counterintuitive to me:
[FAST] 0
[FAST] 3
[SLOW] 0
[FAST] 6
[FAST] 9 <-- HERE
[SLOW] 7 <-- HERE
[FAST] 12
[FAST] 15
The problematic part is when the [FAST] observable emits 9 before the [SLOW] observable emits 7. I would expect 7 to be emitted before 9 as whatever is emitted on the seventh second should come before what is emitted on the ninth second.
How should I modify the code to achieve the intended behavior? I have looked into the RxScala documentation and have started my search with topics such as the different interval functions and the Scheduler classes but I'm not sure if it's the right place to search for the answer.
That looks like the way it should work. Here it is listing out the seconds and the events. You can verify with TestObserver and TestScheduler if that is available in RXScala. RXScala was EOL in 2019, so keep that in mind too.
Secs Event
-----------------
1
2
3 [Fast] 0
4
5
6 [Fast] 3
7 [Slow] 0
8
9 [Fast] 6
10
11
12 [Fast] 9
13
14 [Slow] 7
15 [Fast] 12
16
17
18 [Fast] 15
19
20
21 [Fast] 18
Here is what I suppose: When the code causes a trap (system call or exceptions), xv6 will replace the registers with certain values to transfer the control to alltraps(), in which trap() is called.
But sometimes xv6 runs into trap() out of my expectation, and I want to know why it got into this trap. When debugging, after I set a break point in trap() and xv6 stopped here, I can only see this in the debugger (I'm using CLion). In the call stack, the bottom stack frame is alltraps() so I can't find out when and why the trap is caused.
I want to find out in which file, at which line the trap is caused for a certain call of trap(). Is this possible?
If you will examine trap() code more carefully, you will see that it also handles hardware interrupts (timer, ide and so on).
36 void
37 trap(struct trapframe *tf)
38 {
39 if(tf->trapno == T_SYSCALL){
...
47 }
48
49 switch(tf->trapno){
50 case T_IRQ0 + IRQ_TIMER:
51 if(cpuid() == 0){
52 acquire(&tickslock);
53 ticks++;
54 wakeup(&ticks);
55 release(&tickslock);
56 }
57 lapiceoi();
58 break;
59 case T_IRQ0 + IRQ_IDE:
...
So what are you seeing is hardware interrupt coming and processor transfers control to one of the IDT vectors then to alltraps then to trap(). Most likely you are facing timer interrupt, which is used for context switch.
I want to find out in which file, at which line the trap is caused for a certain call of trap(). Is this possible?
No it is not possible, because this is a hardware event and it has no relation to source code.
I've started to work with Drools Fusion and faced strange issue with during temporal operator. For a reason I cannot make it too work though for example after operator is working fine.
Here is declaration of my event - it just contains an intervals of particular type:
declare WorkingDayInterval
#role(event)
#timestamp(event_ts_local)
#duration(duration_in_seconds)
end
Here is my rule:
rule "Idles in Processing period"
when
$processing : WorkingDayInterval( subcategory == "processing")
$longIdle : WorkingDayInterval(this during $processing, subcategory == "idle",duration_in_seconds > 600)
then
System.out.println ("Bad Idle Event:");
System.out.println ($processing.event_ts_local);
System.out.println ($processing.duration_in_seconds);
System.out.println ($longIdle.event_ts_local);
System.out.println ($longIdle.duration_in_seconds);
end
When I run it nothing is fired.
However when I change during to after I get following results:
Bad Idle Event:
Mon Feb 25 05:19:00 MSK 2013
2350
Mon Feb 25 05:20:00 MSK 2013
901
and looking at the values I clearly see that based on start timestamps and durations second event is inside the first event and so duration should have been fired.
Is it a bug in the Drools Fusion or I am doing something wrong?
BTW - I am running in a Cloud mode
I think the problem is that you are assuming that #duration is measured in seconds when in reality Fusion expects it to be expressed in milliseconds. So, in your case, $processing event starts at 05:19:00.00 and ends at 05:19:02.35 and $longIdle starts at 05:20:00.00 and ends at 05:20:00.90. As you can see, $longIdle during $processing is false but $longIdle after $processing is true.
Hope it helps,
i have the following stack trace:
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
1 MyApp 0x000836bd TFSignalHandler + 28
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
3 ??? 0x00000002 0x0 + 2
4 MyApp 0x000803f1 msgpack_unpack_next + 112
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
...
And i'm wondering how to read it:
I assume i go from the bottom up, eg line 7 called line 6 called line 5, etc.
What does the '+ 112' on line 4 mean? Is that a line number in the code file where it crashed?
What does the '???' on line 3 mean?
Thanks a lot
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
Crash was generated from +[TFCrashHandler backtrace] + 26; from whatever instruction fell at that symbol location + 26 bytes.
If that is really the bottom of your stack trace and it crashed there, then the TCrashHandler is obscuring the real crash. The real crash looks to be a couple of frames above.
1 MyApp 0x000836bd TFSignalHandler + 28
TFSignalHandler was what called +backtrace.
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
Ewww... a signal trampoline. The app received a signal and the a trampoline was set to call TFSignalHandler().
There are situations where a signal handler might be called on a random thread. I.e. there is a minuscule chance that this particular crash had nothing to do with the parser and everything to do with a crash somewhere else. However, without knowing more about the parser, I'd question whether it is hardened against malicious input (which could certainly cause a crash like this).
3 ??? 0x00000002 0x0 + 2
Stack was undecodable. Ignore. Meaningless. Best case; fallout from compiler optimization. Worst case; somebody pooped on the stack and the backtrace mechanism can't figure out what is going on (highly unlikely -- usually, stack poop splatters to the point of preventing a full backtrace).
4 MyApp 0x000803f1 msgpack_unpack_next + 112
Ooooh... trickzy. Someone is using C to parse stuff. And it crashed. Whatever instruction was 112 bytes from the entry point to the function went boom. But, not really, because it called the signal handler and was handled by that; which is still a boom but the signal handler has effectively destroyed additional forensic evidence.
The "trickzy" comment references that an optimizing compiler against a big pile o' C can end up collapsing frames to the point that the crash could have happened in a function well below this one.
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
MessagePackParser was parsing when things went horribly wrong.
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
Ahh... yes.... somebody done grabbed some data from HTTP and it was malformed, causing the crash.
Bottom line; the parser got bogus input and crashed. There was a signal handler in place that tried to help by creating a backtrace, but -- apparently -- didn't really reveal any more info. A long shot alternative is that the signal was generated somewhere else and this thread was randomly selected to handle it -- if you can consistently recreate this crash, the random-thread-signal case is unlikely.
Unless you have a capture of the input data or can somehow guess how msgpack_unpack_next() might crash, you are out of luck without providing more info.
The '???' is something that can't be identified, probably code that was compiled without symbols, but could also be something else.
Those are the line numbers in the implementation file. And the hex is the pointer in memory to the line call.