Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Crash when slicing instanced object. Linux OpenGL? #5745

Closed
smirgol opened this issue Jan 11, 2021 · 25 comments
Closed

Crash when slicing instanced object. Linux OpenGL? #5745

smirgol opened this issue Jan 11, 2021 · 25 comments

Comments

@smirgol
Copy link

smirgol commented Jan 11, 2021 •
edited
Loading

Version

2.3.0+linux-x64

Operating system type + version

Linux - Ubuntu 20.04

3D printer brand / version + firmware version (if known)

Prusa MK3s+

Behavior

  • Download foot.stl from Thingiverse (other objects will do as well)
  • Open PrusaSlicer and drag STL file on printing bed.
  • Add 3 copies
  • Auto arrange
  • Click Slice
  • It will slice but then crash

Expected Results
Not crashing

Actual Results
Crashing

Is this a new feature request?
No

Project File (.3MF) where problem occurs

foot.zip

Additional comment

For this specific object, it will only crash when creating at least 3 additional instances (total of 4 objects). It will not crash with fewer objects.
For other STLs though, it might also crash with fewer instances, but rarely at 2.

It won't crash with PrusaSlicer 2.2.0, but with any version of PrusaSlicer 2.3 (tested with alpha1, alpha4, rc1, rc3)

The problem seems to occur when generating the G-Code.
@lukasmatena
Copy link
Collaborator

I cannot reproduce it (Ubuntu 16.04). Can you please run the application from command line with --loglevel=5 argument if it gives a clue about what is wrong? Are you able to provide any other debugging info (such as a gdb backtrace)? Thanks.

@smirgol
Copy link
Author

smirgol commented Jan 12, 2021

Uhm I unfortunately don't have much experience with gdb. But when it crashed this is what it said:

Thread 1 "slic3r_main" received signal SIGSEGV, Segmentation fault.
0x00007fffec677299 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so

Then I've typed backtrace and this is the result:

#0  0x00007fffec677299 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#1  0x00007fffec679bcb in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007fffecc47a36 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007fffed1208c9 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffed120c88 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007fffed13b41a in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#6  0x00007fffed05fd25 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#7  0x00007fffed069fb2 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#8  0x0000000000c9a7e0 in Slic3r::GUI::GCodeViewer::render_toolpaths() const ()
#9  0x0000000000ca31a5 in Slic3r::GUI::GCodeViewer::render() const ()
#10 0x0000000000c2a14b in Slic3r::GUI::GLCanvas3D::render() ()
#11 0x0000000000cbfaf3 in Slic3r::GUI::Preview::on_moves_slider_scroll_changed(wxCommandEvent&) ()
#12 0x000000000182e1be in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (this=0x237d350, handler=0x2f4a400, func=
    (void (wxEvtHandler::*)(class wxEvtHandler * const, class wxEvent &)) 0xcbfa70 <Slic3r::GUI::Preview::on_moves_slider_scroll_changed(wxCommandEvent&)>, event=...)
    at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/appbase.cpp:657
#13 0x000000000182e232 in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const (this=0x237d350, handler=0x2f4a400, functor=Warnung: RTTI symbol not found for class 'wxEventFunctorMethod<wxEventTypeTag<wxScrollEvent>, Slic3r::GUI::Preview, wxCommandEvent, Slic3r::GUI::Preview>'
..., event=...)
    at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/appbase.cpp:669
#14 0x00000000018c2906 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (entry=..., handler=0x2f4a400, event=...)
    at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1415
#15 0x00000000018c3567 in wxEvtHandler::SearchDynamicEventTable(wxEvent&) (this=0x2d1cb90, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1887
#16 0x00000000018c2d2a in wxEvtHandler::TryHereOnly(wxEvent&) (this=0x2d1cb90, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1608
#17 0x00000000018c40bb in wxEvtHandler::TryBeforeAndHere(wxEvent&) (this=0x2d1cb90, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/include/wx/event.h:3912
#18 0x00000000018c2b9b in wxEvtHandler::ProcessEventLocally(wxEvent&) (this=0x2d1cb90, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1545
#19 0x00000000018c2b32 in wxEvtHandler::ProcessEvent(wxEvent&) (this=0x2d1cb90, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1518
#20 0x0000000000cd5b6b in Slic3r::DoubleSlider::Control::SetSelectionSpan(int, int) ()
#21 0x0000000000cc0c0a in Slic3r::GUI::Preview::update_moves_slider() ()
#22 0x0000000000cc3edd in Slic3r::GUI::Preview::on_layers_slider_scroll_changed(wxCommandEvent&) [clone .part.622] ()
#23 0x000000000182e1be in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (this=0x237d350, handler=0x2f4a400, func=
    (void (wxEvtHandler::*)(class wxEvtHandler * const, class wxEvent &)) 0xcc4090 <Slic3r::GUI::Preview::on_layers_slider_scroll_changed(wxCommandEvent&)>, event=...)
    at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/appbase.cpp:657
#24 0x000000000182e232 in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const (this=0x237d350, handler=0x2f4a400, functor=Warnung: RTTI symbol not found for class 'wxEventFunctorMethod<wxEventTypeTag<wxScrollEvent>, Slic3r::GUI::Preview, wxCommandEvent, Slic3r::GUI::Preview>'
..., event=...)
    at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/appbase.cpp:669
#25 0x00000000018c2906 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (entry=..., handler=0x2f4a400, event=...)
    at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1415
#26 0x00000000018c3567 in wxEvtHandler::SearchDynamicEventTable(wxEvent&) (this=0x2d66380, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1887
#27 0x00000000018c2d2a in wxEvtHandler::TryHereOnly(wxEvent&) (this=0x2d66380, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1608
#28 0x00000000018c40bb in wxEvtHandler::TryBeforeAndHere(wxEvent&) (this=0x2d66380, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/include/wx/event.h:3912
#29 0x00000000018c2b9b in wxEvtHandler::ProcessEventLocally(wxEvent&) (this=0x2d66380, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1545
#30 0x00000000018c2b32 in wxEvtHandler::ProcessEvent(wxEvent&) (this=0x2d66380, event=...) at /home/buildbot/PrusaSlicer/deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/src/common/event.cpp:1518
#31 0x0000000000cd5b6b in Slic3r::DoubleSlider::Control::SetSelectionSpan(int, int) ()
#32 0x0000000000cc4a98 in Slic3r::GUI::Preview::update_layers_slider(std::vector<double, std::allocator<double> > const&, bool) ()
#33 0x0000000000cc4f85 in Slic3r::GUI::Preview::load_print_as_fff(bool) ()
#34 0x0000000000cc59fc in Slic3r::GUI::Preview::load_print(bool) ()
#35 0x00000000009ca507 in Slic3r::GUI::Plater::priv::update_fff_scene() ()
#36 0x00000000009e6328 in Slic3r::GUI::Plater::priv::on_process_completed(Slic3r::SlicingProcessCompletedEvent&) ()
#37 0x000000000182e253 in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const (this=0x237d350, handler=0x2f1eef0, functor=Warnung: RTTI symbol not found for class 'wxEventFunctorMethod<wxEventTypeTag<Slic3r::SlicingProcessCompletedEvent>, Slic3r::GUI::Plater::priv, Slic3r::SlicingProcessCompletedEvent, Slic3r::GUI::Plater::priv>'
..., event=Warnung: RTTI symbol not found for class 'Slic3r::SlicingProcessCompletedEvent'
...)

I'm using an AMD RX5700XT card and the latest oibaf mesa drivers, if that matters.

As for the terminal output, I can't see anything noteable here. But I've attached it anyways. Strange thing is, when redirecting the output it will stop in the middle of "Exported leyer 88", but when not redirecting the output, I get more lines in the terminal - I've attached those additional lines to the log:
logfile.txt

@bubnikv
Copy link
Collaborator

bubnikv commented Jan 12, 2021 via email

@bubnikv bubnikv mentioned this issue Jan 12, 2021
Closed
@smirgol
Copy link
Author

smirgol commented Jan 12, 2021 •
edited
Loading

No, nothing special, really. I'm in expert mode, drag the STL on the bed, hit the "+" button at the top three times to create 3 additional instances, click the auto-arrange button and then hit slice. It slices, generates the G-Code, but then it crashes. But only when I have more than 2 instances (3 objects in total). This differs if I use other STLs, but for this specific one the magic number is 3 objects, anything above will crash.
And it will also crash if I just drag the STL to the bed 4 times and arrange manually, instead of using the buttons.

Okay, what's weird is, that it will now also crash when slicing e.g. the prusa_mmu_enclosure_1.3mf of the IKEA Lack enclosure project from your blog. I cannot remember that it did that in the past.

Edit:
I've re-tested it with my Windows 7 VM, and with that it just works. But on Linux it wont. Since it mentions my GPU driver, it is somehow related to rendering I guess.

@smirgol
Copy link
Author

smirgol commented Jan 16, 2021

I managed to build a debug version and here's a backtrace with some more info (top 10 lines):

Thread 1 "slic3r_main" received signal SIGSEGV, Segmentation fault.
0x00007fffecc85ee9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
(gdb) backtrace
#0  0x00007fffecc85ee9 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#1  0x00007fffecc8824b in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007fffed74f026 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007fffed74f3d8 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffed769daa in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007fffed68e5a5 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#6  0x00007fffed698922 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#7  0x000055555697524a in Slic3r::GUI::GCodeViewer::<lambda(const Slic3r::GUI::GCodeViewer::TBuffer&, unsigned int, Slic3r::GLShaderProgram&)>::operator()(const Slic3r::GUI::GCodeViewer::TBuffer &, unsigned int, Slic3r::GLShaderProgram &) const (__closure=0x7fffffff8190, buffer=..., index_buffer_id=0, shader=...) at /media/Gonzales/compile/PrusaSlicer/src/slic3r/GUI/GCodeViewer.cpp:2043
#8  0x0000555556975980 in Slic3r::GUI::GCodeViewer::render_toolpaths() const (this=0x5555599418b8) at /media/Gonzales/compile/PrusaSlicer/src/slic3r/GUI/GCodeViewer.cpp:2105
#9  0x000055555696a422 in Slic3r::GUI::GCodeViewer::render() const (this=0x5555599418b8) at /media/Gonzales/compile/PrusaSlicer/src/slic3r/GUI/GCodeViewer.cpp:541
#10 0x0000555556886fde in Slic3r::GUI::GLCanvas3D::_render_gcode() const (this=0x555559941060) at /media/Gonzales/compile/PrusaSlicer/src/slic3r/GUI/GLCanvas3D.cpp:5108
#11 0x0000555556870095 in Slic3r::GUI::GLCanvas3D::render() (this=0x555559941060) at /media/Gonzales/compile/PrusaSlicer/src/slic3r/GUI/GLCanvas3D.cpp:1659

It's not consistent though, I also had it crash on bool GLShaderProgram::set_uniform(const char* name, const std::array<float, 4>& value) const in GLShader.cpp, invoked by the lambda function auto render_as_triangles in GCodeViewer.cpp. So at that time it crashed later. Maybe some threading issues? I'm trying to bisect for the exact commit after 2.2.0 that introduced the problem, but there are quite a lot of commits...

@smirgol
Copy link
Author

smirgol commented Jan 16, 2021

It's more difficult to bisect that than I though it would be, as commit ec86d94 unnecessarily introduced an assert(! m_layer_tools.empty() && m_layer_tools.front().has_wipe_tower); into ToolOrdering.cpp that always crashes PrusaSlicer so the actual issue cannot be tested for. It took quite some commits until this was removed, so there are a lot of commits that cannot be tested because of that. I need to do another bisect and remove this assert manually for each test where this is in the code, that will take some time unfortunately.

@smirgol
Copy link
Author

smirgol commented Jan 17, 2021 •
edited
Loading

The commit that introduced the crash for me is this one: 535a27d

This fixes the crashes for me:

diff --git a/src/slic3r/GUI/Gizmos/GLGizmosManager.cpp b/src/slic3r/GUI/Gizmos/GLGizmosManager.cpp
index e3bb964ad..1c977c7b9 100644
--- a/src/slic3r/GUI/Gizmos/GLGizmosManager.cpp
+++ b/src/slic3r/GUI/Gizmos/GLGizmosManager.cpp
@@ -413,7 +413,8 @@ bool GLGizmosManager::gizmo_event(SLAGizmoEventType action, const Vec2d& mouse_p
 
 ClippingPlane GLGizmosManager::get_clipping_plane() const
 {
-    if (! m_common_gizmos_data
+    if (!m_enabled
+     || ! m_common_gizmos_data
      || ! m_common_gizmos_data->object_clipper()
      || m_common_gizmos_data->object_clipper()->get_position() == 0.)
         return ClippingPlane::ClipsNothing();

I'll also create a pull request.

Edit: Meh, it still crashes...

@smirgol
Copy link
Author

smirgol commented Jan 18, 2021

I'm still unable to pin down the issue, there are just to many commits and structural changes to test. But I think it's buffer related. When I try to load a gcode file, it will crash when generating the index buffer, or shortly after when it's trying to use the buffer. That's the same when slicing most objects, it will crash in the render lambda function, so something is off there that for some reason works on older systems but not on mine, which is bleeding edge driver wise.

@lukasmatena
Copy link
Collaborator

Just so that you don't think that nobody cares. I'm glad that you started investigating and am watching you. Sadly, I cannot reproduce the problem and although I investigated 535a27d, I did not see how it could break anything.

@bubnikv bubnikv mentioned this issue Jan 25, 2021
Closed
@aburubh
Copy link

aburubh commented Jan 25, 2021

I'm experiencing the same issue here after upgrading to the latest ver. of PrusaSlicer as it crashes crash while slicing a large object with high infill, or multiple small objects which takes time to print, and the issue is consistent and I can reproduce it.
to check it out, you can test with "Core_J_Primo_V1.STL" from https://www.thingiverse.com/thing:4493589 and follow the designer specifications by making the infill 70%.

The same object was working perfectly with the previous ver. of PrusaSlicer, for now I'll reinstall older ver. until the issue is fixed.

@lukasmatena lukasmatena mentioned this issue Jan 26, 2021
Closed
@tullo-x86
Copy link

Hi, I'm the reporter of #5889. I found a workaround on my machine, which was to disable Mesa's use of DRI3 by starting PrusaSlicer with LIBGL_DRI3_DISABLE=true prusa-slicer. Not sure if it'll work here, but it's worth a shot.

If it does successfully work around the issue, please say so; it could help the devs get to the bottom of it.

@aburubh
Copy link

aburubh commented Jan 27, 2021

Thank you for your feed back.
I'm not sure how / where to set LIBGL_DRI3_DISABLE=true, I did try to do that in the Environment Variables but it did not work for me, I'm still experiencing the same issue.
BTW, I'm using Windows 10.

@smirgol
Copy link
Author

smirgol commented Jan 27, 2021

Thank you for your feed back.
I'm not sure how / where to set LIBGL_DRI3_DISABLE=true, I did try to do that in the Environment Variables but it did not work for me, I'm still experiencing the same issue.
BTW, I'm using Windows 10.

That is a setting for Linux, it probably won't do anything on Windows. But it's interesting, that a similar thing seems to happen on Windows too.
I happen to have a virtual machine for a Win7 installation that I do need for Fusion 360, so meanwhile I run PrusaSlicer 2.3. in that one for now to be able to use the latest features. It didn't crash yet - but it's a virtual machine.

On a side note, crashes got even worse for me. I'm now unable to slice even one of the objects mentioned in my initial post. I rarely can slice anything successfully in 2.3. on Linux by now.

@smirgol
Copy link
Author

smirgol commented Jan 27, 2021 •
edited
Loading

The issue seems to be fixed on the latest commit d68489c.
My tests before were done on commit d06aa60 from 15th of January.
There have been a couple of changes to files that I suspect to be the cause of the crash, but I haven't pinned down what actually fixed it.

@smirgol
Copy link
Author

smirgol commented Jan 27, 2021

Commit ee40ab4 seems to be the one that fixed the issue.

@tullo-x86
Copy link

Commit ee40ab4 seems to be the one that fixed the issue.

Interesting. I reproduced my issue using the prusa-slicer-git package from AUR, which pulls down the default branch (master), and I built it on Monday (2021-01-25). I wonder how recently that commit was merged to master?

@smirgol
Copy link
Author

smirgol commented Jan 27, 2021 •
edited
Loading

The commit is from 21.01. while the version in AUR is from 18.01, so it's missing that specific commit. If I'd know how to build an AppImage, I could provide you with my binary.

Edit: Sorry, I've tried for quite some time to build said AppImage, but to no avail. Best option would be to update your git repo.

@tullo-x86
Copy link

I see you aren't familiar with AUR packaging — the prusa-slicer-git PKGBUILD in AUR fetches the latest source from GitHub every time it builds. All of the -git packages do this. Any non--git package pulls a specific tag or commit, and any -bin package downloads binaries and repackages them for an Arch installation.

At any rate, I've found my workaround until this gets fixed. Hopefully what I've reported is enough information to help the devs find the root cause.

@smirgol
Copy link
Author

smirgol commented Feb 24, 2021

FWIW: It's still crashing sometimes, even with the latest commits, especially when trying to slice in 0.3 Draft Mode, but at least it works to some degree now.

This was referenced Jul 13, 2021
Closed
Closed
@bubnikv
Copy link
Collaborator

bubnikv commented Sep 2, 2021

Is this issue still relevant? Is it reproducible with PrusaSlicer 2.4.1-alpha1?

@tullo-x86
Copy link

tullo-x86 commented Sep 14, 2021 •
edited
Loading

It's still reproducible in v2.3.3 on my machine, but it's a lot more difficult to make it happen:

  • Arch Linux
  • Zen kernel v5.13.13
  • KDE Plasma v21.08.1 (X.org)
  • Mesa v21.2.1
  • Radeon RX 6800

My guess is that it was a race condition, and Mesa's performance between v20.3.x and v21.0.x managed to mess with PrusaSlicer's expectations pretty reliably.

Today I had to work hard to make PrusaSlicer crash, slicing Benchy a dozen times with different settings before it segfaulted.

@bubnikv bubnikv changed the title Crash when slicing instanced object Crash when slicing instanced object. Linux OpenGL? Sep 25, 2021
@nikel123
Copy link

It looks like some bug in mesa AMD radeon drivers and mesa threaded opengl stuff. It doesn't crush on me if I run prusa slicer with the following env var: mesa_glthread=false prusa-slicer
Also narrowed it to prusa slicer gcode viewer, it crashes if one tries to open the problematic gcode.
As a workaround one can also just generate gcode by choosing export gcode from the menu. In this case gcode viewer isn't triggered and slices don't crash.

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 23, 2021

We cannot support Linux OpenGL driver issues. Closing.

@bubnikv bubnikv closed this as completed Oct 23, 2021
@tullo-x86
Copy link

tullo-x86 commented Oct 25, 2021 •
edited
Loading

Honest question here: If this is truly a problem with Mesa, why does nothing else crash?

If the issue only occurs at the intersection of [widely-used driver that flawlessly runs everything else] and [niche software which sets up a condition where that driver fails], is it really meaningful to blame the issue on the driver?

And if so, how on earth are we supposed to report this to the Mesa developers when we don't have a way to reproduce the issue beyond telling them to "run this arbitrary program which has a zillion degrees of freedom, with these specific inputs — no really, it's not the application it's your driver trust me"...

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 26, 2021

@tullo-x86
Honest question here: If this is truly a problem with Mesa, why does nothing else crash?

Frankly I don't know. I only know that the state of the OpenGL support on Linux is not good, that we don't have the resources to dig deeper into your issue and that if we leave the issue open that we will just stumble over it over, then we will close it in two years. What do you suggest?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@nikel123 @tullo-x86 @bubnikv @smirgol @lukasmatena @aburubh